Network Security Internet Technology Development Database Servers Mobile Phone Android Software Apple Software Computer Software News IT Information

In addition to Weibo, there is also WeChat

Please pay attention

WeChat public account

Shulou

How to turn the back-end Baas

2025-02-22 Update From: SLTechnology News&Howtos shulou NAV: SLTechnology News&Howtos > Internet Technology >

Share

Shulou(Shulou.com)06/01 Report--

How to turn the back-end into BaaS, in view of this problem, this article introduces the corresponding analysis and solution in detail, hoping to help more partners who want to solve this problem to find a more simple and feasible method.

In fact, the core of BaaS is to encapsulate our back-end applications into RESTful API, and then provide services to the outside world. In order to make the back-end applications easier to maintain, we need to disassemble the back-end applications into micro-services free of operation and maintenance.

There is a degree to be grasped in the disassembly and merger of micro-services, because there are costs in the process of dismantling and merging. If we disassemble it too carefully, it will inevitably lead to the growth of our calling link. The longer the call link, the first impact is the network delay, which is easy to understand. After all, if you have a long way to go, there may be more "traffic jams". The second is the increase in operation and maintenance costs, the longer the call link, the more fragile the whole chain. Because problems in one of the links will lead to access failure of the entire call chain, and it becomes more difficult for us to troubleshoot the problem.

On the other hand, if we disassemble it too thick, the call link is short, but the reusability of this micro-service is poor, not to mention the complex and redundant database table structure caused by high coupling, which makes it difficult for us to maintain later. I drew a picture. Feel it.

Dismantle it

If we want to disassemble the micro-service reasonably, how should we disassemble it? As I mentioned in the last lesson, the mainstream solution is domain-driven design, also known as DDD. DDD is an idea put forward by Eric Evans in his 2004 book of the same name, but it has been confined to the circle of Java. It was not until the rise of microservices in 2014 that it was discovered that it could guide the separation of microservices. To sum up in one sentence, DDD is a set of methodology: through the hierarchical abstraction of the business, analyze and define the domain model, use the domain model to drive our design system, and finally disassemble the complex business model into a domain model with independent operation and maintenance.

In fact, in the process of using micro-service development, I found that micro-service as a whole should be a dynamic network structure, and this network structure will change with the development of business. DDD can help us to analyze a better network structure, but in fact, we should think more about how to optimize the dynamic network as a whole: reduce core nodes, protect core nodes, reduce network depth and so on.

How to understand dynamic network optimization? We can do a thought experiment: suppose we disassemble all the functions into micro-services, and any micro-service nodes can call each other, and the more frequent the invocation, the closer they are. So let's consider, when the traffic of access requests on our website is stable, what is the network state of our entire micro-service node?

First of all, the mutual restriction of network nodes will always make those nodes which are strongly dependent on each other and highly coupled get closer and closer, and finally gather into a cluster of nodes. Secondly, those nodes that have nothing to do with business logic are gradually marginalized or even disappear. Let's look at these nodes that gather into clusters. If the nodes in the cluster are too close, they are actually not suitable for splitting. They should be made into a micro-service as a whole. After the clusters that are too close to these nodes are merged into a micro-service node, we can see that the nodes that are gathered together but not too close are micro-services.

Therefore, when we start the project, we don't have to worry too much about how to disassemble the microservice. Instead, we should continue to pay attention to and consider the rationality of each micro-service node. Just like looking at dynamic networks, continuously adjust the optimization and remove the core nodes. Eventually, it will accompany the development stage of your business and achieve a stable and dynamic network structure at all stages.

Fit it

As we have seen above, the disassembled architecture is a dynamic network, so how should we merge or orchestrate it? Of course, you can use traditional functions like SFF to process the request results of each HTTP data through an array or object, and then return these results. But here I'd like to introduce you to another kind of choreography, workflow.

We can think of the user's request as our respiratory system, our lungs are SFF, and microservices and FaaS nodes are the organs that need oxygen. We take a breath, the oxygen enters the lungs, and the blood circulation flows the oxygen sequentially through each of our organs, which is the request link. As soon as each organ receives fresh blood, it absorbs oxygen and returns carbon dioxide, which eventually circulates to bring carbon dioxide to the lungs to exhale. This is the data return link. Our organs are strung together by events that require links to arrive through fresh blood. This is the flow of events, that is, events are used to connect FaaS or microservices.

Authentication

In fact, the security provided by FaaS is usually placed on triggers. The authorization type or authentication method of the trigger can be set to anonymous anonymous or function function. Anonymous method does not require signature authentication, and anonymous users can access it; while function method requires signature authentication [4], this signature verification algorithm, parameters need to use the access key of our account ak/sk [5], ak/sk is equivalent to the bank card password of our cloud account, so important account information can only be used on the server side, and must not appear in the front-end code.

To solve the security of back-end Intermodulation, we use VPC or IP whitelist, which is easy to solve. What is more difficult to deal with is the trust problem of the front and back end, and JWT just provides a solution to the trust chain. Of course, with regard to authentication, some cloud service providers have launched some more secure and easy-to-use BaaS services, such as AWS's IAM and Cognito.

Security is an important part when we consider architecture design, because the failure of security architecture design will directly lead to the loss of our assets. Authentication is used to identify users and prevent the disclosure of user information and malicious attacks. But according to my statistics, 99% of our daily problems occur during the launch of the new version.

When our project is Serverless, the quality of the code becomes particularly important. If you think about it, before Serverless, you accidentally launched a bug, which affected only one application at most. But after Serverless, if the core node releases a serious bug online, then the scope of influence is all online applications that depend on it.

However, you don't have to worry too much, both microservices and FaaS have the ability to iterate quickly and independently. In the past, the iteration cycle of one of our applications usually took one to two weeks. However, for Serverless-based applications, each node can be released online anytime and anywhere with the help of independent operation and maintenance.

To sum up, we know that both microservices and FaaS iterate quickly and fix problems quickly, but we can't wait for problems to arise every time and then rely on this capability. Is there any way to find the problem in advance to ensure that we are fast and stable? At present, the best practice of software engineering is the release pipeline of the code pipeline.

Publish Pip

There are three main parts of the pipeline for publishing pipelines:

Pre-release verification, code test coverage CI/CD

Simulated traffic regression test passed and released to grayscale environment

The code is officially online, and the grayscale environment replaces the formal environment. The result of each node of the pipeline will be used as a necessary starting parameter for the next node.

Let's take a look at the picture above, and let me explain the process.

After our code is merged into the specified branch, I usually use the Develop branch.

The hook of Git will trigger the subsequent pipeline and begin to enter the build packaging and testing process.

What the test node does is run all the test Case and count the coverage.

The coverage is verified, and the code example is verified by recording traffic simulation.

The simulation verification passed, and the code example was released to the grayscale environment.

According to the grayscale strategy online, a small part of the traffic is imported into the grayscale environment to verify the grayscale version.

In the grayscale window period, such as two hours, if the grayscale verification is not abnormal, replace the official version with the grayscale version; otherwise, discard the grayscale version immediately and stop the loss.

At present, the release processes of larger Internet companies are basically running like this. If you don't know much about it, you can try to build it yourself with the Serverless workflow introduced by us or the workflow tools provided by cloud service providers. On the basis of this process, many enterprises will also set environmental isolation assembly lines and security bayonets in order to pursue higher stability. For example, isolating the test environment and the online environment, the test environment is used to reproduce the failure. Every time the code enters the release pipeline, it must first run through the test environment, and then release the security bayonet before it can enter the assembly line of the online environment.

This is the answer to the question about how to turn the back-end BaaS. I hope the above content can be of some help to you. If you still have a lot of doubts to be solved, you can follow the industry information channel to learn more about it.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.

Views: 0

*The comments in the above article only represent the author's personal views and do not represent the views and positions of this website. If you have more insights, please feel free to contribute and share.

Share To

Internet Technology

Wechat

© 2024 shulou.com SLNews company. All rights reserved.

12
Report