Front-end early chat conference, a new starting point for front-end growth, jointly held with the Nuggets. Add wechat Codingdreamer into the conference exclusive push group, win at the new starting line.
The 14th | front-end growth promotion, 8-29 will be broadcast live, 9 lecturer (ant gold suit/tax friends, etc.), point I get on the bus 👉 (registration address) :
The text is as follows
This article is the 44th lecturer of front-end Early Chat, and also the sixth Serverless special session, shared by Guang Yi from 1688 team – brief edited version of lecture notes (please see video and PPT for the complete version with demo) :
One, foreword
About me, the specific name of our team is Alibaba CBU Technology Department-Experience Technology-marketing & Engineering team. The whole team is responsible for the front-end engineering infrastructure and DevOps of our CBU BU, as well as the development of the whole front desk marketing guide scene.
I was recruited to join this team after graduation in 2016. During these years, I mainly built the page building system, preferring wireless building, and then did some shopping guide scene development and front-end engineering infrastructure, which is to share some things related to Serverless with everyone.
Second, the background
Next, I would like to share with you the following aspects: first, under what scenario we will introduce Serverless architecture, what supporting peripheral construction we have done after the introduction, and finally, what we are doing for the future based on the existing basis.
We’re facing the middle and back
1688 website is a type B e-commerce business under Ali’s e-commerce system, so we have a large number of middle and background systems supporting operation, specifically, a large number of applications based on Egg framework. From the perspective of application structure, this kind of background application is mixed with various forms of structure such as Web MVC layer, scheduled task and RPC service, which is not easy to maintain.
Another problem is that these apps are typically long tail apps, with a pulse-like distribution of traffic; For security reasons and to avoid a single point of risk, the application must also be equipped with at least three machines, resulting in very low resource utilization of the machine.
During the development process, developers also need to master a lot of knowledge related to operation and maintenance to make the application smoothly serve online. In the era of the rise of the full stack, people gradually began to use Node, but at the same time, they had to bear a lot of trivial costs of operation and maintenance, which was actually a very big limitation for everyone’s development. In this scenario, the concept of Serverless gradually emerged in the industry.
Introduction of Serverless
Teacher Zhao Bing has also summarized the concept of Serverless, which can be divided into FaaS and BaaS. From the perspective of product architecture, it can be summarized into four characteristics:
- In terms of products, it advocates the allocation of resources on demand, which can fully improve the utilization rate of resources.
- In terms of architecture, it advocates stateless computing containers that you put in Serverless, such as FaaS, which advocates stateless computing because it is easier for it to expand and shrink. In this way, when it expands and shrinks horizontally, it doesn’t affect the availability of the function because there are a lot of states in the application.
- From the human point of view, from the whole stack development trend, we gradually use Node to do server development, in fact, with a general trend, from before we go to write CLI tools, to a variety of Web Framework began to rise, will gradually do Web development.
- From the perspective of cloud vendors, until now, major cloud mainstream cloud vendors have also begun to launch their Serverless solutions, such as AWS, Google, Microsoft and other Top vendors, they will do their own Serverless solutions.
After a series of internal investigations, we finally decided that a solution called Ginkgo was more suitable for us. You can see Ginkgo’s simple architecture diagram above. Ginkgo uses a Sidecar model to Broker all traffic through RSocket brokers. The entire flow of traffic between functions is realized through the Broker pattern, whether it is imported from the access layer into the function itself, or whether it is called from inside the function to a third-party service outside.
Gingko’s solution provides very low-level capabilities, focusing on the allocation and scheduling of the entire container, as well as its scaling problems. At the access layer, different RPC, HTTP and MQ triggers are provided. It also supports message, cache, RPC middleware, but lacks native DB read and write capabilities. Moreover, the ability of the access layer is too low, such as unified login authentication, self-defined domain name and other common appeals in the middle and background are not fully supported, so our construction is to solve these problems.
Iii. Program introduction
segmentation
As shown in the figure, the focus of the overall solution is divided into three parts:
- The first is to build a separate gateway according to our needs;
- The second is to establish an online unified RESEARCH and development process platform;
- The third is to complement their existing BaaS capabilities that we need.
Under this solution, what are the traffic flows of its two main types of users?
Coming in from a developer, it needs to initialize the function according to its own needs, create iterations, develop quickly, and finally deploy the function to live service. When a function is deployed to a container environment, a user accessing it will pass through the gateway of the whole unified access layer. In the gateway, we will do, for example, when we define different routes and different domain names for it, and when the function is in some scenarios with high SLA requirements, we will do some fault tolerance for it. It is convenient to do this at the unified gateway layer at this time. Login authentication, however, is a state that does not need to be maintained in a large number of functions, and it is also a good choice to do it in the entire access layer. When the whole flow passes through the gateway and then triggers to the access layer of the container environment, it passes through the flow of the internal flow and then returns after calculation in the function. This is the process of the whole flow.
Let’s see what we did in between.
In the first background scene of the whole function, we need to provide the frequently used function template, so that the initialization will be more convenient. We analyze a common middle and background scene, which high-frequency modules may exist in it. We use Egg more, so if it wants to make its writing habits more suitable, the whole FrameWork of Egg needs to support this kind of semantics.
The second is the ability to provide it with a common external server.
The third is its ability to follow messages with timing.
The form of functions corresponds to the types of functions that are supported throughout Ginkgo, the type of HTTP and the type triggered by the messaging middleware. On top of that, HTTP can be modified to support the application Framework pattern. Then based on this analysis, we finally developed four suitable function models for the whole background scene. The whole function model is in the whole Serverless. If you think of it as a different layer in a container, first traffic will enter the Proxy layer of the whole container entrance, and then there will be a unified Runtime in the container to accommodate the communication between the upper function and the lower container. To provide a clean, unified layer on which to introduce a different Framework on which to run the user’s entire code.
After the whole r&d process has a complete application model, how to define what it needs in the whole R&D process?
The overview
First of all, if only the traditional pattern of the CLI, the whole process is roughly like that, the development of the debugging of initialization it need what ability, and then build, deploy, and deploy it to the container environment, a server application running to online, after the necessary is log debug to monitor such ability, and to make this function is to access, There needs to be a unified access layer. The whole research and development process platform is to put the whole ability gradually online, online in the process, can let it have a unified and consistent model.
At the time of initialization based on a function template, the initialization process is a natural process, mainly in the development, development needs more is to be able to let his Debug, at the time of deployment build, if it is to do in your local, the construction of the CLI big probability may appear inconsistent people rely on environment. Therefore, we prefer to be online. Online, through Docker, can have a unified and consistent environment and maintain the consistency of the environment, which will also be safer. Finally, when it comes to the whole access layer, the layer that the previous introduction of the whole access layer needs, the layer that can be abstracted out in general, can replace the very primitive, directly through Nginx reverse proxy pattern that is difficult to maintain, so that it can be configured more efficiently.
As for what the specific product looks like in the whole process, there will be some schematic diagrams and some small innovations we made during the construction of the R&D process will be introduced. For example:
A function release process may need to do grayscale will certainly have multiple versions coexist, how do we determine whether the current version is effective? We designed a mechanism based on CommitId. When this function needs to be iterated, its code must be changed. The whole code must have a unique CommitId in GitLab, which uniquely identifies its current iteration. It can become something like a blood line to mark the current version.
And then how can this version be perceived from the outside? We take an approach that defines a default route built into the Framework, reading a file on a specified path that contains the entire version. The next crucial step is to connect the two. The whole build process is connected with the whole development process, so you can pull down the code of the version that needs to be deployed during the whole build process, and get its Commit information through some means and then plug it into the corresponding place. During deployment, it is convenient to know whether the current version is the expected version through the URL that can be accessed from the external public network.
Another common requirement is that local development support remote debugging. Javascript development fortunately, Chrome provides a very good mode to support breakpoints, and NodeJS also provides the underlying capabilities for developers to enjoy this convenience. How can we make it easier for developers to do function development? Going back to the layered model of functions mentioned above, functions are based on the Runtime, and on top of that is the App Framework, an extensible Framework that allows us to do a lot of things.
To support this remote debugging, we built a simple Webserver into the Framework. Webserver is mainly used to provide some Open apis. The Open API uses the Inspect protocol provided by Node itself to operate the entire Node application in the current container, enabling remote debugging in it, a debugging protocol that works well with Chrome.
The diagram on the right shows a complete address that was assembled during development. This address makes it easy to see the entire debug panel when Chrome is open, and it is very natural to debug the entire JS code as the front-end browser side JS.
When we look at the access layer, what capabilities do we need in the middle background when we access the access layer? First, it needs to know which custom domain names we are accessing, and how it knows that I need to route to the function I specified when I give it some default domain names.
So it’s more important to make an agreement. In the process of making an agreement, actually all the teams in our group are doing similar things. We discussed a standard of cooperation and construction based on Swagger OAS and made some extensions on this basis. Based on this protocol, it is deployed throughout the release process. When it after this function deployment to the container, this time is really no way to directly through the access layer visiting asked about it, because there is no way to access layer when the function between the connection between the request context, this time you need to put these requests synchronization into the access layer of context.
After the whole access layer senses the information, when the traffic request comes, it can sense which function serves the address of which request through the pre-established protocol in the whole access layer, as well as its sub-path to the following, which is the core logic of the whole access layer.
After the core problem of the whole access layer is solved, in fact, what remains is the capability of the BaaS layer, which provides three of the four mainstream middleware: cache, message and RPC. However, the other one was not well solved, and the whole team may have their own plans. However, when we landed and wanted to have a capability, we adopted a pragmatic approach, and the whole function was not designed very complicated. Because in considering our itself faces the background scene, the history of the Node, a Java application, they are all with very large stock of the scene, and then they have before the old database, has been running well, big probability are apply for a new database may cost may be higher for them, because the cost of data migration is higher.
Second, in the background scene we considered, its traffic is not that large, so their entire architecture may not need to consider too much, such as high availability and the extreme performance, mainly to solve the problem of our scene at that time. So on this basis, we actually borrowed its mature capabilities, such as RPC, to build a function on the basis of the entire RPC, the function can access the entire database gateway through RPC, and then the entire database gateway, such as Node, the most basic capabilities encapsulated very thin. What it does is it gives you the ability to remotely execute a piece of SQL through RPC, and then on top of that it encapsulates more possible ORMs, different types of ORMs and the SDK for this query, the SDK takes the previous example where we need to unify login information and call different middleware, These capabilities are packaged into an SDK and built into the template of the whole function, so that everyone will be very unified and convenient to use.
Next look at when we use a screenshot, for example to create the entire online process, it will help you create the entire warehouse, and after creating the warehouse, it will go to choose different function template, based on this template to do initialization, after the initialization is through GitLab associated with its branch of that kind of model, This makes it easier to separate the code and roll back it.
Then specific to the development process, after the deployment of the entire development process, it is very convenient to see the need to see its operation and maintenance information in different places and how to call it.
Iv. Follow-up planning
With this set of patterns, development experience compared to before there are a lot of ascension, because under this model, in fact, after you read the document for the whole process is very simple, do not have any operational costs, and the whole development process level May Day from before to now possible at this level will be able to finish development hours, For the whole development process is actually very convenient. And to think about it a little bit more in this mode, because the whole function it’s just we’re using it in the background, and the whole mode as we review it, is actually a very general computing mode, right? Its entire definition of this container-to-function model can be tried more in our higher level business scenarios.
But when we gradually move it to the kind of shopping guide that is common in e-commerce, when we copy the previous set of models, we will find that it may not work. Why does it not work? First of all, we can compare, if we common in the background scene and in the kind of shopping scene, its function inside the composition is about what? In the middle background scenario, as I said before, it actually has a lot of coupling, it has to deal with different layers, it has to deal with different computational models, and in it it may define its own data model, this domain model.
But a guide to the scene, such as a guide in electric business scenario, I buy on a page, I want to display a list of goods, I will show a list of merchants and the activities of its favourable information, these are modeled, it is fixed, this model is very mature, this concept in it, Our guide in the scene inside to use it you will find the whole function code complexity compared to the background, its complexity is reduced, it reduce the whole domain model is that it does not need to maintain its function itself, it is mainly to do the data inside cut out this thing, then spell it needs in the whole View of this layer data, This is actually a very common pattern in BFF in the shopping guide scenario.
Under this model, we further consideration, the background scene is likely to be in before we’ll be the first to different logic, to define the domain model, the process may be so, but guide in the scene for this model, we think this direction may be, in turn, because first of all, it has been such a model, we need know what model, And then this model we might need to know what fields there are, and then on top of that field, we might use the function pattern to compose it in the foreground View scenario what does it need? So its scenario in BFF is probably more of a mode of producing functions from the model, which is probably a faster mode than the middle background can make the whole BFF development process possible.
Follow-up planning is also a model that we are doing now. Whole we will establish a unified model in the field of market or bazaar, and then we’ll give it defines the whole field model is complete, as this document and the way in which the whole call this kind of information, can let whole BFF developers can very fast perceived model in which place, I need these models exactly what inside it, In this way, it will be more convenient to develop it. The entire BFF function is built on top of it.
Then such as model, the model of its stratification, DDD which advocates a model of hierarchical, and we choose what kind of pattern, from the bottom of the whole infrastructure, before has done the whole function of the access layer of the entire development process, all can be attributed to the level of the entire infrastructure, The solution is the whole function in the technical level of the development of the problem. On this, the foundation is to model the domain in the field of category, the first is common in different such as electricity this domain, the domain above may define different model, in this model, we need to go to the outside world, when using this model may be two different way of thinking, The first is to provide a two-sided packaging-like model, an SDK that lets users rely on the SDK. There’s also a mode that you can call in a unified way, a form of RPC, and then be able to call in a unified way, rather than relying very heavily on one SDK for this mode. On top of this whole invocation, there is an environment in which the whole function runs. The figure on the right is an example of a model generated function that we envisioned earlier.
More specifically, what we might want to do is to have a model where the whole model is layered, the whole domain model, the whole market of the model is sort of layered, from the innermost primitive data dictionary all the way to the outermost, looking at the information of the model through the GUI, With the Open API being able to be integrated by different service providers, we will be able to make the entire model accessible through a unified call portal.
This model what does it actually have in this one? First model is very pure, such as very pure, like the commodity business model, it does not need too much business logic, it needs very clearly define each field and the field of information, some very general methods on this field, this pure domain model, and then there are in this model, Do we need to crop this model for different views? But the process of tailoring, it may be able to be re-used, which is also a very common pattern.
In fact, this mode is to describe the original information of the whole function by matching it with a Scheme protocol after it is run. With such original information, such a processed function that is higher than the pure domain model can be regarded as a model. And then back into the market of the whole domain model. To do this, you need to define a very complete protocol for the entire model, which contains at least the original information about the model, such as its input parameters, a field such as its return type, and its calls, one of the forms of calls it supports. Another is that when it is a model that orchestrates the form of the function, it flows back into a model that may need to clearly define which model is derived from further upstream.
Because with this information we can do at least two things, the first is to determine the pedigrees of the entire model, and even more accurately do the pedigrees of the entire field. In this way, when using this model, we can see the flow of the blood relationship of the whole field, which is more convenient for us to troubleshoot problems in a very long and distributed link. The second thing is that with this model, you can go one step further and generate code based on such a unified protocol. What do you mean? That is, when we can clearly know which upstream models our BFF script depends on, we can clearly know at the time of its creation what kind of call logic these models are, the call logic, and how to write this code, It can be done in an automated way.
And if we could do that, imagine that even as we went through the development process we could tick off what models it needed, and what method fields it needed in those models, and with that we could generate roughly 60 or 70 percent of this code that we could use, And then on this basis to do development, the whole process will be very convenient.
Team to introduce
Next, I would like to advertise that our team is the experience Technology Department. The experience technology Department of CBU is actually our department at the front of the whole CBU, and our department usually goes out a lot of activities.
In fact, internal sharing may be more than going out activities, we will also invite some industry leaders to share, to expand our vision.
This may be everyone’s favorite big sky little sister, is also our team. In fact, we are very active inside, and there are more students who are so active, such as Big Sister.
This is before we went out to build.
This is a daily activity, and we will also be doing some activities during Programmer session 1024.
This is our internal AI programming contest at 1024, and this is the situation during the contest.
Many activities are organized on birthdays.
If you are familiar with quadratic elements, there are many students in our team who are good at playing quadratic elements.
If you are interested in what our team is doing, or if you have any questions or questions about what I just said, you can add my contact information, and we can discuss together. As we can see in the whole construction process, we are actually in a process of continuous construction and exploration, and this is an external public account of our team. In the public account, our team will regularly share some good technology and some trends in the industry.
That’s all for my share!
This article is formatted using MDNICE