Original Address: Liang Gui Zhao's blog
Blog address: blog.720ui.com
Welcome to public concern number: "server-side thinking." A group of the same frequency who grow up together, along with sophisticated, breaking the limitations of cognition.
First, fled single system, embrace micro services?
The difference between the monomer system and micro services that a single system is a large and comprehensive set of functions, each server is running a full service for this application. The micro service is autonomous and independent functional modules, which is part of the ecosystem, and other micro-service is a symbiotic relationship. Now, the industry generally views on single systems and micro-services are: monomer system is very easy to develop, test, deploy, but the problem also faced by many single system, such as the development of low efficiency, maintenance costs, affecting the deployment change large, can be poor scalability, high cost of technology selection, and the introduction of micro-micro services can implement each service easy development and maintenance, to facilitate communication and collaboration, it is suitable for small agile team development and continuous delivery; each micro-duty service a single, high cohesion and low coupling. At the same time, each micro-development services to independent, stand-alone, independent deployment; are independent between each micro-service, if a service deployment or downtime, it will only affect the current service, will not produce the entire business system impact; each micro-system services can continue with the expansion of the scale, the face of massive and high concurrent user, do independent horizontal expansion and vertical expansion; each micro services can use different programming languages and different storage technologies, making us more easy to try new technology. In addition, a single service for business reconstruction, will not face a great burden on business and technical bonds.
The author views on the micro-service system, the process of our transformation from a single system to the micro-service system, we need to seriously think about what stage the use of micro-services. Micro service is not a silver bullet, it is for the design and operation and maintenance requirements of a higher degree of difficulty, but also brought some of the complexity of the technology. Therefore, we need to think about and address the complexity of distributed, data consistency, management and operation and maintenance services, service deployment automation solutions. In fact, the micro-service system by splitting the monomer to become smaller volumes plurality of services to reduce the complexity of the individual services, however, from the overall point of view, this approach has resulted in the presence of a large number of services, the service call will also increase with each other, resulting in the overall system architecture becomes more complex.
We often ignore the business value and cost considerations, and the pursuit of too much technology, it may lead to our well-designed, distributed architecture seriously affect our development speed and rapid iteration of business, and with the uncertainty often leads to our business architecture in six months to one year had not fully applicable to reinvent the wheel. In addition, if the business is not developed can lead to blindness wasted a lot of pre-server resources, which for start-up business more harm than good. Therefore, we early in the project in order to ensure the rapid growth of the business, ensure the system to minimize reliance and independence and integrity, reduce the complexity of the technology after the introduction of micro-services architecture, for example, it is difficult for the operation and maintenance of a higher requirement, because good microService architecture requires a stable infrastructure. With the good business development, the system will continue to expand the scale of its extensibility, scalability, availability and performance are limited to our business development, at this time, we, with a clear business thinking and devote more resources to again consider micro service transformation.
Micro-service architecture using the service as a modular unit, so we can rely on preliminary isolation by Maven module in the modular design of the early time, to reserve space for reconstruction after us. Note that the micro-ecosystem services in a symbiotic relationship. Here, they are not confined to the possible link dependent, while their business value must be symbiotic. Thus, post-recognition systems monomers core values, function key, and then split into separate these functions and self-complete module. Here, rehabilitation programs can read the author of "micro-availability scalable service architecture: based on Dubbo, Spring Cloud and Service Mesh" "micro Services Architecture transformation of legacy systems," Chapter XII of the book.
In summary, micro service by splitting the monomer system to become smaller volume of more services to reduce the complexity of individual services, but we on the whole, this approach has resulted in a large number of services exist, and services call will also increase with each other, resulting in the overall system architecture becomes more complex. Therefore, we do not just focus only on technology, but need to consider input-output ratio, to maximize the protection of the interests of the current stage.
Second, get rid of the monomer system to stay away from the big ball of mud?
Monomer system a lot of people criticized poly confusion within its services, it looks like a big ball of mud. Then, after a Service, to solve this problem? In fact, micro-services by splitting the monomer system to become smaller volume of more services to reduce the complexity of a single service, so look more functions of a single system is clear, however, the overall system architecture becomes more complex. In fact, it calls between multi-service production environment possible scenarios as shown.
Typically, micro-ecological production service environment is more complex than the above case, there may be dozens to hundreds of services. So, for us, how to systematically sort out the relationship between dependency and link the service is very important. Especially when big promotion, the need for strong protection to the core link, the job becomes even more important. In this regard, I recommend automated link combing through traffic collection of APM.
In addition, we design the architecture, partitioning problem whenever there are service granularity, for example, create a new project, or for when the service boundary ambivalent, we need to discuss clear boundary for service, so that our services remain cohesive as possible sex.
Third, the migration service can improve system robustness micro do?
Here, there is a prevailing view: a single system is a large and comprehensive feature set, if a service fails, the entire business system will have an impact, however, the use of micro-services deployment can be achieved if a service or dang machine, only affect the current service, without affecting the entire business system.
In fact, this view seems very correct, but in real-world business scenarios, the key is not to promote the cause of our transformation. First, a monomer in order to avoid single points of failure, will certainly require clustering and load balancing, noted that, and micro-clustering and load balancing services (vertical split service) are not mutually exclusive relationship, but in highly concurrent and distributed in symbiotic relationship. In addition, in order to solve service deployment, we can consider rolling release is achieved by no interruption in service. Therefore, the monomer system is not necessarily robust. Meanwhile, after the introduction of micro-services, on the whole, this approach has resulted in a large number of service calls between each other's services will also increase, causing the entire system architecture becomes more complex, on one link the probability of a node failure is greatly increased, more reliance also means that more problems may occur. In this case, assuming that one of these micro-service bar on a call link is down unable to provide services, then rely on its strong upstream service, how to ensure their own usability? (I am here especially strong dependence calls, service degradation or fuse mechanism might be detrimental to business, effective program is not addressed.) Thus, in many scenarios, a service outages may also affect the entire business system.
So, if we do not fail for design and build a service system of governance, it will lead to the robustness of the overall service.
Fourth, migration services can improve the performance of micro-systems?
So, what is the migration of micro-services main drivers of? I think the most important benefit motivation is to enhance the scalability and performance considerations services. A service because of limitations of the host machine may reach a bottleneck, in order to further squeeze more machine resources, split the service it is a good idea. At the same time, we can also automatically shrink further expansion to adjust the use of the machine. However, the migration service will be able to improve the performance of micro-systems? My point is not necessarily true. After the service of, the call link becomes longer, once the original RPC communication may become several times, the performance loss is increased. For example, one major challenge is to live off-site network delay, delay across the city there will be a problem, assuming that cross-regional network latency possible in less than one hundred milliseconds, an HTTP request involves a two hundred cities across the RPC call , then the entire response time will increase a lot, so the challenges brought about by the delay very large. So, Ali order to solve the problem of data delay, the first unit of the proposed solution ideas, make a request soon converge to the same area is completed, the unit within the high polymer, do not do cross-regional visit, the "unit closed." In addition, there is also cross-network service call timeout problem by retrying the synchronization also increases the risk of obstruction.
Therefore, the service performance of the expense of calling on the link between services, to improve overall system performance for the entire business press machine resources to improve the system.
Fifth, the availability of micro-services = services provided by each call are reliable and available?
For the availability of micro-services, many people understand that the service provided by each call are reliable and available. This view is not right. In fact, micro-services to ensure the overall availability of their services. Typically, if the service A calls service B, if you call 10 seconds, then the situation might clog the latter, indirectly, led to the thread pool explode, resulting in service is unavailable. Therefore, we will take a timeout response mechanisms to guarantee complete results within a very short period of time, blocking the synchronization problem is avoided wherever possible.
In addition, if the service B fails, all calls will depend on the service appears blocked, if there are a large number of requests causes the thread resources are consumed completed, resulting in paralysis of service. In fact, the dependency between the service and the service will cause a cascade propagation, thereby indirectly cause "avalanche" effect service failure, cause the entire micro-services system is unavailable. To solve this problem, the fuse mechanism comes into play.
Sixth, micro-services database are mutually independent and transparent?
A mainstream view is that micro-services, each service has its own cache and database and cache and database are mutually independent and transparent. Therefore, the shared cache and the shared database is wrong. If you need to get that data service A service B how to do? The general practice is to provide a service B acquires the API interface data, the service A performs business assembled by invoking the interface. Therefore, after the micro-service, data exchange between the services are carried out through the interface, if service A service data access services across the B between business logic B, which would undermine the independence between the micro data service .
At this point, I need to pour cold water it. Nothing is absolute, there are several special scene may need to share data. First, it is the old service transition to the new service scenarios, new service functions and data multiplexed in order to reach the needs of the transition with the old database services. Second, it may rely on the same data source among a plurality of services, such as data aggregation report. In this case, if we simply rely on the RPC interface calls it is likely to lead to call a timeout sporadic, resulting in a greater chance of failure. So, to solve this problem is the usual routine sharing of data, or data redundancy data synchronization by the way, followed by data aggregation within the boundaries of locally-based services; centralized ETL or data warehouse through a number pulled out of the program, and then Foreign re-processed data. Third, more realistic cost. In fact, more databases will bring more funding costs. In many cases, we will consider the issue from the funding cost. We choose to reuse the original database table, after waiting for a clear business value, then consider a separate independent database.
Meanwhile, data sharing technical solutions to avoid costly and repeated the context of data migration between data unclear circumstances, and can more easily adjust the size of the service when needed, and then after the data migration service granularity and stability. Therefore, we must seek the proper balance between the two, to comply with the mainstream view of possible micro-service, full use of the benefits of micro-services.
Seven organizations to protect micro-services implementation?
Micro service and organizational structure put forward new requirements, it is recommended that a large team split into multiple small teams, and each team developed their operation and maintenance and operation and maintenance of one or more services, and continuing to deliver the required processes, continuous deployment, DevOps.
Different services may be provided by a different team development and maintenance, under real-world scenario, convenience services more micro-house team that can generate closed-loop, in other words, internal teams can be easily developed and maintained to facilitate communication and collaboration, but for external team there is a big cost of communication and collaboration costs. As shown, team A for the understanding of the service C is a black box, we do not know it is single service or micro-services, it has deployed several servers, which need to rely on downstream services, the existence of current limiting, fuse and demotion strategy, and how to access. If we need to make sure these issues, under normal circumstances, they require manual coordination and confirmation.
Of course, this is an organizational division of labor brought the inevitable question, then we try to ensure the cohesion of our own in-house service team, to be divided about the service module, to ensure the independence and integrity of the micro-services business, as much as possible less dependent on the existence of services, chained calls. Here, it throws a new problem. Micro Services how "micro"? In fact, the split service is not as small as possible, even extreme case is to split a function as a service, this approach is wrong. Therefore, split size should ensure the independence and integrity of the micro-services business has split split around business service module. If the value of the business split into separate services / technical value is not clear, then let it be coupled in the monomer system, throughout the life of the project had already sufficient. If with the development and business needs, we can adjust with the modular structure of the system source code level, and splits it into separate micro-services.
Sometimes, the team has the absolute ownership of the project, so as to consider the interests of the team and the emergence of micro-production services on a "semi-finished products." I believe that this case is not unique, but the vast majority of the norm. Now, we look at a case. A team considering the reusability functions and developed a "interactive components," including the "block comments" feature. At this point, B team did not know also developed a similar "interactive components." The C team also have this demand, it knows that team A has this "interactive component" in the hope can be reused, but because of this "interactive elements" in the design of more consideration of the current business team A, there is no good complex use of, for example, does not support "comments Gailou" function, and because team a reason for the current progress of other projects can not provide support immediately after the C assessment team decided to spend a week in line with its own development "interactive components" on your business needs . In this case, each individual project teams maintain an "interactive component." In this case, because the responsibilities of the border between the teams resulted in limitations reuse services, or even result in fragmented nature of the situation, this generally requires corporate level planning and co-ordination. Coincidentally, Team A and Team B in a single system work, but both need to integrate in order to ensure that both the interests of the two teams, they are not breaking the original architecture fusion, but to identify areas on the basis of the original boundary .
Furthermore, assuming that the external RPC interface to a less stable, the general practice is to analyze the causes of instability, but in the case of cross-team cooperation, external service might be a black box, and is probably a wall of invisible wall between the teams, so the cost of communication and collaboration is very large, this time need someone to lead the whole link so that everyone's interests to reach agreement. Well, today is the most efficient way possible is the internal team to circumvent this problem by other means, such as redundant cache or interface adapter. Therefore, it is perhaps the current program to maximize the business value of Jiaoyou under the organizational structure and the environment, we need to adapt to the current and future prospects. When it comes to the interface adapter, there is also a very common micro-architecture design services: service mode adapter. Typically, the external service to our message body and inconsistencies in format we need, at this time, we have to push them seem unlikely to transform reality, then, in order to protect our business logic without introducing a large number of service adaptation logic, we will be introduced into the adaptation layer (adapter services), the message body will be adapted to external services on a standardized form, and then exposed to service up, e.g. refund adaptation, adaptation and other logistics.
Therefore, the company organized to determine the impact of the service boundary to a large extent. Under normal circumstances, we do divide areas within the boundaries of their own team to meet business needs as much as possible, although from a technical point of view this is a "semi", but it is perhaps the Jiaoyou maximize the business value of the current environment Program. The so-called long period of division, when we see that it has a sufficiently large value, further integration is also a good idea to consider.
Written in the last voices
Finally, we come to talk about the introduction of new technology, technology to bring the project dividends. A new learning technologies need to consider the costs and maintenance costs, and the availability of protection and operation and maintenance. For example, in the operation and maintenance of my escort, I can ease the use of various technologies in the company, but I do not necessarily dare to use MongoDB in another company, because I know I am not an expert in this area of operation and maintenance, if problems arise, I may not be a solution. So, the introduction of a new technology technical risk may exist. Very often, we fail to be based on the design, this is precisely the gap between the junior engineer and senior engineer. For example, Redis achieve distributed lock, a lot of people only think of how to implement this logic in code, but if Redis cluster master service hung up, switch directly to the service, because it is the primary synchronization from an asynchronous, and distributed lock the emphasis is certainly the latest data lock only works, it works at the moment is that, this time distributed lock lost data, your business will result in repeated requests, distributed lock if used in a business, you must it is important scenes, especially in the financial and payment, so a single-point version of Redis distributed lock is not a good way, not use, if you do, you have to solve the stability problem. (Quote "high-availability scalable micro Services Architecture: Based Dubbo, Spring Cloud and Service Mesh". Author "Cheng Chao 'share of cases in the group, particularly wonderful) Here, under a little tricky question, back to the topic, we You will often find a new project to try to use new technology, while older projects are more conservative, because the former is less costly trial and error. Interestingly, the new company is more sensitive to the development of technology, such as many small companies have a lot of practice and landed in a cloud of native ways. At this point, you probably know about the views I expressed: Under normal circumstances, the use of technology stack is behind the company's operation and maintenance support, as well as to control the force of the technical depth. So, we need to reserve in advance of new technologies, ready on the battlefield, but in most cases, we want to ensure and maximize the business value of existing technology (tools).
In summary, this article precipitated a lot of practical thinking and I saw and heard since the work, the key point is not to sing the decline of service, but let us remain independent thinking, out of a purely technical perspective to think about architecture, to look at micro services, to ensure that maximize the business value of existing technology (tools).
Written at the end
[Server] thinking: We talk with the core server technology to explore the architecture and project experience in front-line combat Internet. Let alone all of R & D personnel to find their own circle of exchange, to explore. Here, we can upgrade the cognitive connection top technical Daniel, connection excellent way of thinking, connected to the shortest path to solve the problem, all fine way to connect, to break the limitations of cognition.
More exciting articles, all in "server-side thinking"!