Foreword: This article is excerpted from the article "Talking about the microservice transformation of back-end business systems" in the 201606 issue of the "Architect" journal of infoQ, author: Zhang Xu; the literature related to this article includes: 1) "Microservices (Translation Version)" 2 ) "Microservices (Original)" ; many thanks to the many authors for providing us with such excellent documentation!
1. Introduction
The business system is a necessary component of any user product, and acts as a facade. The user's input is what the system needs to maintain, and data access is the core of the entire system. For example, the input of the advertising business system is the advertising constraints and targeting conditions of the advertiser, and the input of the microblog business system is short text, pictures, etc.
In the early stage of application development or when the scale is small, there are very simple implementation solutions. LNMP, JSP, and PyWeb are all words you can say casually. If you describe it in a certain architectural way, it can be called a single unit. mode (Monolithic, proposed by Martin Flower, which will be introduced later), and these technologies are mature solutions of the single mode, they can make you work at the top of the "application layer", various middleware, frameworks It allows you to do your business with peace of mind. Developers can manage the complexity of business systems through "modular" means, so that they can be decoupled and reused. In simple terms, this monomer is the following hierarchical division.
Front-end presentation layer (HTML+CSS+JS) | | Logic layer business system (PHP, Java, Python are commonly used languages) | | Data Layer Database (MySQL)
It seems simple enough, right. It is true that business systems still need to do a lot, such as caching, SQL optimization, data partitioning, system security, and of course code maintenance and refactoring. This way of working can work well for a few years or even ten years, but if the business develops very fast, and the system complexity, business scale, number of participants, and code corruption continue to rise, you will find that the entire project is Stuck in the quagmire, PM/RD/QA/OP often complain:
"If you change a small function, why do you have to pull so many modules?"
"Just pulling the module, there are many places to change, and the compilation is too slow."
"It's okay to be slow. I don't know how to change the key. This code is too ugly. Forget it, in order to meet the PM's scheduling needs, make do with it."
"It's okay, QA finds bugs, rework and rework, delay and delay."
"On line, oh my god, reported a case, there is a performance problem, it turns out that the dependent module accesses the database using a for loop select."
Looking at the essence through the phenomenon, I summed up the three questions:
1. The business logic is complex and coupled, and the development and maintenance costs are high.
The complexity, scale, and number of participants of the system are all proportional to the degree of corruption. By simply relying on modularization, some modules will become "big monsters" in the later stage, which are bloated, too coarse-grained, and difficult to reuse.
2. Low delivery efficiency and quality.
Today, when agile and continuous integration methodologies and practices are popular, the iterative on-time delivery rate and single-test coverage rate are not satisfactory, and online problems occur frequently.
3. Non-functional requirements are not up to standard.
Non-functional requirements indicators specifically refer to performance, usability, scalability, etc. Corruption of code, lack of maintenance, refactoring, and pollution by people without code cleanliness will inevitably lead to gradual decline in performance, and even the short-board effect of competition for different resources. , causing the entire system to crash. At the same time, a large monster has poor scalability, and cannot expand a certain subdivision function point horizontally at will.
I think anyone who does architecture needs to adhere to the idea of "business needs determine the technological evolution route", then these exposed status quo and problems will drive the system to transform, find an optimal cooperation model between the system and people, and match the Existing productivity and generative relationships. As software development guru Kent Beck said:
"Design is there to enable you to keep changing the software easily in the long term"
Looking at the industry, in the face of complex, large-scale, multi-person collaborative business systems, there are many ways to manage this complexity, such as modularization, OSGI, traditional service-oriented SOA, etc. The trend of today's best practices is still Service-oriented, and micro-services is a concept that has recently become popular. Some people must think that this is not a hype, but no matter whether a black cat or a white cat can catch mice, it is a good cat, so solving the problem is the key. Don't deliberately criticize some names, then This article will focus on how to do microservice transformation and transformation.
Before the next talk, it is important to declare that this article does not advocate service-oriented, and does not encourage the single model. On the contrary, it is quite affirmative and supports the single model. It has simple module dependencies, a release package, and deployment in a container. The application is very simple. When the volume is not large, the first solution is to build an absolutely stable platform based on modularization. After the volume gradually grows, it can be split according to actual needs. It also changed accordingly (facebook's single unit lasted for a very long time, one is the high quality of personnel, and the other is that the basic platform construction is very good). In the next stage, if the volume is so large that it suffers from the monolithic model, platform-based services should be built first. After the construction is completed, they should be divided according to large granularity, and then gradually micro-serviced. Otherwise, service-based, Even the microservices mentioned below are very dangerous and have few success stories.
2. Microservice transformation
There are generally three steps to doing a transformation:
First, technology selection decision
Second, the architectural design planning
Third, implement the application on the ground.
The following three parts will be expanded in turn, focusing on the first two steps. With these two, the landing application will be easy to do.
2.1 Technology selection decision
2.1.1 Choosing a Microservice Mode
Choosing a service is known as SOA. This is an architectural style that focuses on high-level thinking such as principles, concepts, and methodologies. There are no mandatory restrictions on tools, frameworks, and solutions. ESB, websercie (based on WSDL and SOAP/ BPEL) These two are popular in enterprises, and they are also the technical leaders that have led SOA in the past. However, with the development of Internet applications, the requirements for agile and rapid iteration, high availability, high performance, and high concurrency are getting higher and higher. Traditional SOA is not suitable for this scenario. So, what is the current popular implementation of the Internet? One of the best practices is Micro Service. [with picture 1]
Microservices are just an implementation of SOA. They focus more on the subdivision and evolution of services, and are a practical way to guide the specific implementation of services. In the past, many Internet companies have practiced. You can regard Taobao's dubbo, HSF, and navi-rpc service-oriented frameworks as service-oriented frameworks that are more suitable and closer to micro-service implementation than traditional SOA. Relying on these frameworks can be easily service-oriented . This trend was discovered by Martin Flower, who proposed that you are all doing "microservices".
Martin's interpretation of the term microservices (terminology) is:
In short, the microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies.
In short, microservices is a methodology that develops and supports an application with a series of small services. The services are independent in their own processes and interact through a lightweight communication mechanism (usually using the HTTP protocol). These services are built around the organizational structure of the business and are fully automated and independently deployed. There is little to see a centralized service management infrastructure, and different services can be implemented using different programming languages and data storage technologies.
A simple understanding comes from a book "Building Microservices" (Sam Newman, O'Reilly Media), Microservices are small, autonomous services that work together. Microservices are a bunch of small and autonomous services that work together work up.
Compared with the traditional SOA, Martin's summary features can refer to his blog and video ( Youtube link ). There are a total of 9 features. I don't want to go into details here, but to talk about my personal understanding. The features of microservices are:
1. Module as a Service
The components in microservices tend to be subdivided at the logical or physical level. This subdivision is not extreme, but a choice with moderate granularity. Usually these components can be some modules in the early stage, but when needed, such as business It can be flexibly disassembled if it needs to be split and independent, or if it needs to be expanded in terms of non-functional requirements . This feature is very important, because the modular practice in business systems, as the scale of the software becomes larger, it is easy to bypass obstacles and make the coupling of different modules and the complexity of dependencies. This discipline is difficult to guarantee, thus weakening the modular structure. , reduces the productivity of the team (agile development and continuous delivery are getting harder and harder to do, the deployment is too large, everyone's development morale is low, and it is painful), and soon this module will become a hodgepodge, and services can do When it comes to natural barriers, interaction is only done by exchanging contracts (usually API or proto). This is an evolutionary process, which is not only conducive to divide and conquer, but also to achieve the purpose of reuse. At the same time, the old system can also be transformed and stripped in grayscale.
2. Independence and self-government
This means that services are independently developed, independently tested, independently released, independently deployed, and independently operated and maintained. A subdivision team is responsible for the entire life cycle management . This is the popular explanation of " Conway's law ", the official explanation It is "the design result of an organization, and its structure often corresponds to the communication structure in this organization". Isn't service planning a communication mode of multi-person and cross-team collaboration. The advantage is to abandon the original train model (all modules are released and deployed together) and embrace independent running, which also better supports the practice of agile and continuous integration methods. At the same time, the problem of affecting the whole body is removed, and a single responsibility is used to modify requirements or reconstruct a point. It is convenient to develop and build, and does not affect the function of the entire product. A bug will not crash the entire product. , distinguish between computing-intensive and I/O-intensive, distinguish whether it is better to use relational or NoSQL in business, distinguish the 2/8 principle, that is, 80% of frequently modified services are independent and independent, distinguish short-board functions, and can do levels for bottlenecks Expand, avoid resource competition, and even differentiate technology stacks and break through language restrictions. Finally, this also echoes the first point. Independent services can be reused to a large extent, and services rely on lightweight interfaces instead of modules.
3. Decentralized data management
In the monolithic mode, an application faces a set of databases. The database can be physically split, shard partitioned, or isolated according to logical libraries. Different services are routed to different libraries, and they can be structured as one master and multiple slaves at the same time. Design , these principles still apply in microservices, but microservices also need to separate the database when the service is split, and independent services maintain independent databases, which also reduces the burden on the database, and at the same time, technology selection and SLA guarantee will be Distinguish them, leave the energy to those important business databases, and treat them in a hierarchical manner, instead of treating them equally as before. The bad SQL slow query of an unimportant logic library blocks other normal queries, which can be completely avoided. of.
4. Lightweight communication protocol
Traditional SOA uses heavyweight solutions such as ESB or Webservice. Microservices recommend using some lighter solutions. For versatility, you can use Restful architecture, take HTTP channels, and support Json serialization protocol; for high performance, you can Consider some high-performance I/O models, such as epoll, Actor, etc., you can directly go through the tcp channel, use the protobuf serialization protocol, and maintain a long connection (here is an example of Navi-pbrpc is such a specific landing framework); Asynchronously, use reliable and durable RabbitMQ or high-performance ZeroMQ for P2P, Pub/Sub, and broadcast broadcast message communication. And this kind of lightness also needs to be reflected in the code call. The modularization can be called directly through functions and methods. After the service can be achieved at the API level without intrusion, seamless switching, and simple configuration, these are all services. the framework to be supported.
5. Design for Failure
Service calls have changed from in-process calls to cross-process distributed calls. This natural unreliability caused by distributed characteristics needs to be relatively controllable. That is to say, the communication between services should be assumed to be unsuccessful and handled as failure. Can the transmission of exceptions be restored locally on the caller through RPC, just like function and method calls? At a point or when the processing error rate of the service reaches a threshold, in order not to affect the entire product, to isolate the error, you can consider means such as circut break, bulkhead isolation mode, current limiting, and fallback. Finally, there is a power Equivalence problem, whether the retry call will affect the business, this needs to be analyzed in detail.
6. Infrastructure Delivery Facility Automation
This feature is the biggest highlight in the whole microservice, including the combination of continuous integration CI, continuous delivery CD and PaaS platform. In the context of subdivision of microservices, the project structure and physical structure have increased the complexity. If we want to improve the overall efficiency of the software delivery link, we need to make a big change in the basic delivery. Therefore, DevOps culture, let everyone participate in the delivery, under the standardized process and standard delivery (for example, standard container), and with the help of PaaS service provider, complete the automatic deployment and release of a service.
Everything has two sides, there are good advantages, of course there will be disadvantages. My understanding of the disadvantages of microservices is as follows:
- Performance and latency issues caused by distributed calls. (Actions that can be taken include moderate granularity, batching, high-performance RPC, asynchronous communication, etc.)
- Reliability is not guaranteed. (The design for failure just mentioned can be solved)
- Data consistency is difficult to guarantee. (Look at your respective business and ensure eventual consistency. In fact, most Internet products rarely use transactions; but the commercial product field I am currently working in requires transactions. In addition to the not recommended two-stage submission, you can also Introduce arbiters and compensation measures to solve the distributed transaction problem. The problem can be introduced in a separate article, and will not be expanded here)
- Overall complexity increased. There are many services, many dependencies, many calls, how to manage contracts, how to monitor, how to determine which point is wrong on the call chain, SLA guarantee, performance, error rate, alarm, how to integrate and test so many services, and how to launch delivery containers And so on. (Through service governance, the inefficiency caused by the complexity of microservices can be effectively reduced, and the efficient evolution of engineering productivity can be promoted. At the same time, the automation of infrastructure delivery facilities can accelerate the efficiency of research and development. Choosing microservices means choosing a cost priority strategy. Costs are all for the better development of future business, avoiding the J-curve R&D model, and only when the volume is large, the infrastructure includes a service-oriented framework, and on the basis of perfect governance capabilities, plus processes, specifications, tools and skills. Only with the assistance of the service, can the power of service-oriented be truly exerted, otherwise, we will have to ask for trouble)
2.1.2 Microservice framework and governance model
A consensus has been reached on the structure and principles, and you can look down. After the virtual talk, let me introduce some dry goods. Let me introduce the microservices practiced by my team. The core is the microservices framework. The industry's popular Ali's framework dubbo and Taobao's internal HSF and Navi-rpc can all be regarded as microservices. The prototype of the service-oriented framework, coupled with the management of the service governance center and the guarantee of the basic delivery facilities, can constitute a complete set of microservices framework. The overall architecture of our framework (for the time being only used internally) is shown in the figure below. It consists of a service publisher, a caller, and a governance center, which belongs to the standard coordinator model. [with picture 2]
The service logic in the producer is in the beans of the IoC framework such as Spring or Guice, and is managed by the IoC container. In order to conform to the idea of module as a service, a set of pluggable component engines is implemented at the framework level to implement component scanning. When the exposed service is released, if it depends on other services, the Rpc call proxy Stub is generated through bytecode technology, forming a component-based container, which is connected to the J2EE container through the JSR315 standard SPI implementation. The following consumer structure is the same.
After the service is started, it will first register itself to the service governance center, upload its own contract and version, and the governance center will publish it if it passes the inspection. Simple) Make a channel for subscription and publishing, which can be used to collect status and push changes to service Endpint; service consumers can go to the governance center or Maven repository to obtain contracts and SDKs, and the governance center pushes the Endpoint down for routing to make Rpc calls through consumers. The status and statistical information are also reported through the long connection protocol for the governance center to make analysis, decision-making and feedback.
In order to ensure high availability, the service governance center usually uses Zookeeper, a popular open source Paxos-based solution. Of course, the recently popular etcd of kebernetes is a Raft-based solution for cluster sharing data and service discovery.
As such distributed calls become more and more frequent, the service governance capability needs to be stronger and stronger, otherwise it will be a chaotic and disordered network of Rpc calls, unable to manage the complexity.
A service governance model is established here, which is implemented by the service governance center in the figure below. The model considers how to manage services from several perspectives, including communication, contract, version, monitoring, security, delivery, etc., relying on the service governance center, With the protection of this infrastructure, servitization can truly improve R&D efficiency and provide an elegant development experience. [with picture 3]
In terms of the automation of infrastructure delivery facilities, as shown in the figure below, it is reflected in the process of automation and containerized delivery. In the context of platformization, the team thinking is transformed into DevOps-style, relying on Docker and k8s to complete the docking of the PaaS platform, and at the same time Cooperate with QA to complete the establishment of continuous delivery process. [with picture 4]
2.2 Architecture Design Planning
The architecture referred to here refers specifically to the architecture design of organizations and services, as well as non-deployment and code architecture.
What I want to introduce below are all deductions, it is a service-oriented transformation of an existing system, and it is an existing, complex, and large-scale business system.
Architectural design planning is mainly divided into steps:
- 1 Overall Architecture Design
- 2 Business domain abstraction and modeling
- 3 Service Planning and Hierarchy Division
- 4. In-service process, data, contract (interface) definition and technology selection.
The first three steps are mainly introduced here, and the fourth one is biased towards individual cases. At the same time, it needs to be analyzed and solved in combination with business requirements and characteristics. It will not be detailed here.
2.2.1 Overall Architecture Design
Remember the monolithic model that the article said at the beginning? In a complex and large-scale business system, the implementation of microservices requires the overall architecture from top to bottom. The following picture is the architecture diagram from the business side to the retrieval side of my commercial product. [with picture 5]
It is divided into 5 levels.
The first layer , modular assembly, is the facade of each product launch. Each launch product can be assembled by building blocks to assemble lower-level services to complete a user-oriented function. The most common SpringMVC technology, Java design pattern in the The facade pattern is some of the points that apply to this layer.
The second layer is the computing service layer. Serviceization is developed at this level. Each small circle is a microservice, which is the core of the entire serviceization. Each service circle is a service cluster, such as Trafficking one cluster, reporting reports one cluster.
The third layer , the data storage layer, will be split for each business and isolated according to physical libraries or logical libraries.
The fourth layer , the advertisement transmission layer, transmits the advertisement increments written by multiple shards of MySQL to the retrieval end in real time to form an incremental data stream. We simulate it as a slave library of MySQL to capture and parse the binlog implementation. , which incrementally maps binlog to language-level abstract types for downstream use. The next layer is a data receiver, and the others include some MQ subscribers (such as importing kafka, RMQ, ZeorMQ, etc.), HDFS storage, etc. It forms the purpose of fast, efficient and real-time transmission of data in the business system.
The fifth layer , the retrieval terminal. It is the core of the advertisement delivery system. It matches the best advertisements according to the media environment and user characteristics, and carries out creative delivery. The pictures, H5, and flash advertisements you see are all responsive to this system, which can be achieved in front of thousands of people. Optimizing the tradeoff between advertiser ROI and user experience.
2.2.2 Business Domain Abstract Modeling
Technology is for business. Without business, pure technology is just talk on paper. Solving problems is the starting point of all technologies, and microservices are no exception. To serve the business, it is necessary to have a deep understanding of the business, so that the technology can form a good output.
With the overall architecture planning in the previous step, the next step is how to plan the microservices in the computing service layer. This part is the most complicated and needs to go deep into the product business. Of course, it is possible to pat your head for planning. This is called empirical intuitionism. I think that empiricism lacks standardized expression and standardized design. In the face of future modification needs, the vitality of its architecture will not be very strong. We should try to solve it from a higher perspective. The first is to standardize the expression of demand. The following figure is an expression of delivery implementation. It is expressed in the Bacchus paradigm (BNF paradigm) , and the delivery implementation is divided into audiences, media, scenes and other orientations. Each orientation is divided into multiple constraints, which are deepened layer by layer. This specification is the extraction of all existing products and needs to be followed in the creation of new products, and is generally created together with product managers. [with picture 6]
Then, the standardized design of the function matrix division of each released product can be based on these, and service planning can be carried out with reason and evidence. The abstractly decomposed service domain has high cohesion, very clear responsibilities, and the entities in the service are also modeled. , as shown in the figure below, each package is a microservice. [Picture 7]
2.2.3 Service Planning and Hierarchy Division
Based on the abstract decomposition of the business, within the computing service layer, more subdivided hierarchical planning can be carried out. First, it is divided vertically into three vertical layers: presentation layer, computing layer, and data resources. The core computing layer is further subdivided into 3 vertical layers. Each layer, including the business process processing layer, completes functions by assembling lower-level services; business logic components are self-contained, cross-product line, and highly reused components; the following public service components are some general services. It is then divided horizontally into multiple service clusters. As shown below. [Picture 8]
According to the previous service plan, each microservice is placed in it. The top-level web-ui and api services are responsible for dealing with front-end js and client-side (Android or iOS) APIs. In the middle, such as promotion and management of workflow as a business process processing component, The following microservices can be called to organize and complete a business scenario of the delivery process. All these services are communicated and governed through a distributed service-based framework.
2.3 Implement the application on the ground
The following is a case of the transformation of an existing product, such as a report service cluster, which used to be a large unit, and is now split according to the service-oriented architecture. The core is the middle sync-report service, which is derived from the olap engine. Query data, and then merge literal data to provide sorting, filtering, and paging functions. Multiple caches of different dimensions are extracted around sync-report, which ensures the high performance of the core report service. At the same time, the upper layer, whether it is web-ui or api, reuses sync-report, so that the upper layer will be very thin and no longer need to be managed. For those complex query logic, sync-report, as a standard and standardized technical solution, achieves unified reuse and full-time dedicated use, which accelerates R&D efficiency and delivery. [with Figure 9]
3. Afterword
The microservices advocated in this article are based on the characteristics of the author's team's own business, and are suitable for their own scenarios. They are based on the quality of team personnel, mature infrastructure and frameworks, middleware assistance, and standardized processes, including CI. , agile, etc., the team has done a good job of making this change accurately, and has enough capabilities to implement it, and microservices are a matter of course. On the contrary, it is not suitable for small teams to choose microservices in the early stage or during the barbaric growth period, which not only affects the efficiency but also brings additional complexity . Growing or large companies have mature processes, specifications, infrastructure, platforms, etc. If they want to accelerate the entire delivery chain, they need to invest more resources to ensure microservices, everything is automated and can be managed, In retrospect, it was all worth it, and the long-term returns were impressive.
The last thing to say is that architectures are just standards, skeletons, and the discussion of microservices shouldn't let us forget the more important issues, the important factors that drive the success and failure of software projects. Soft factors such as the quality of the people on the team and how they collaborate and communicate with each other can have a big impact on whether to use microservices. On a purely technical level, it is the fundamental responsibility of a software engineer to focus on clean code, complete testing, and continuous attention to the evolution of the architecture.