This article altogether is divided into three parts, namely the evolution of the micro-service architecture, application technology and transformation practice fields of micro-services designed to drive awareness. Micro-service architecture has *** into all aspects of Internet applications, and domain-driven design also gradually be received by the industry.
Almost all micro Services Architecture architecture evolved from the monomer ALL IN ONE, in the middle also experienced a distributed architecture, the evolution of service-oriented architecture.
Monomers architecture often chimney-type approach to development, often there are two main problems: centralized and high coupling. The so-called centralized, data is centrally stored in a single database, centralized business systems deployed on a single server, providing service capabilities through the cluster deployment, however, the center of the problem, is a single-point problem. Coupled high, which mainly refers to a functional module upgrade, upgrade had with other modules. To note here, the wrong module depends not high monomer architecture, because the original architecture might not designed, however, in the actual scene, with the rapid development ××× Diego, developed for a wave after wave product walked crop of another crop, inevitably corrupt system architecture seriously.
See many problems monomer architecture, the system starts by split by function or module, split into multiple independent subsystems, called via RPC, MQ way between systems, which gradually evolved into a distributed services architecture. Distributed Services Architecture mainly resolved by decoupling the service and hierarchical, "the tidy road infrastructure" mentioned in the book that can degrade system for the policy level and, while architecture is the same strategy assigned to the same component in contrast, belong to different components. Therefore, the architecture can be layered design, a high level of service call low-level service, low-level service up to provide services through the interface, in order to achieve decoupling between the systems. It was also during this period, all of a sudden single architecture is split into several or dozens of systems.
But with the development of architecture, but problem after another, in the absence of good demarcation of the border, the system splits the service tend to be loose. As the "clean architecture of the Road" talking about: software architecture design itself is the art of dividing a boundary. Therefore, many systems at this stage, is often carried out within the evolution and level of service to gather. The so-called service within poly, is to domain-driven design principles, redefining the boundaries of the field of integrated services modules, the system consolidation. Hierarchical away, it is the removal of the high and low levels of service points, service calls by providing the best link service requests, reducing the depth, in order to ensure stable system performance.
How the system from 0 to 1, from 1 to 2, from 2 to 100, in practice the process of micro-services is not easy. First of all, the first question to consider is: What is micro service? In fact, the service is a micro action: demolition. When it comes to demolition, it involves two questions. First, how removed? Second, to what extent the demolition.
The first question, about how to dismantle, need to focus on two levels, the hair version of speed, such as iteration speed and the speed of development in different fields of commodities, trading, marketing, etc. are inconsistent, therefore, should be split into different areas, otherwise, it may be coupled together, must be followed by the A-B line on together, it might be merged together. Another energy collaboration, behind each corresponding to a different system of research and development team, a project often takes several teams division of labor, then the system will inevitably lead to split the cost of teamwork, so the split system is also split the team, to consider cooperation communication costs brought about.
The second question, to what extent the demolition. In fact, there are already a lot of people on the micro-services are defined, which I consider the most important points: First, a set of micro-micro services or services should be deployed to run an independent service, the second is the micro-data service depends resources should be isolated from each other independent deployment.
In fact, just the beginning of the demolition of micro-practice services, to build a micro-service overall framework but also for tetralogy: demolition, service oriented, high availability, isolation.
1, the service Split
Micro-service pay attention to split, so much is the micro-micro, as well as, how is the more reasonable split. In the field of architecture, we are talking about a well-known law: Kang law can be understood as: organizational relationships is a system architecture and corporate relations team matches. The transaction will correspond to a trading system development team merchandise will correspond to a system of commodity research and development team, this responsibility clear organizational structure will make the system more efficient development.
(Picture from the network)
"Future Architecture," a book AKF told a cube model, the complexity of latitude from about three split function, horizontal expansion, the resulting data partition, if only one system, a single deployment, a single point of storage, then it It should be just a point, because as the magnitude increases, the system has been increasing in every latitude, has become a huge cube.
(Picture from the network)
The system can be divided into split split split split the functionality and the reader. As a single system, in accordance with the user's interaction scenes look, the portal home page can be split into reception systems, category, product, search and other functions can be split into commodities center, about orders, payments, invoices and other functions can be split into trading center, which is a simple system to split and split functions. And some more specific features, such as the detailed page provider, the polymerization needs to read when reading, so they can read and write split.
2, a Service
Micro-services first need to have micro-services infrastructure, no micro-services infrastructure, micro-services practice is a disaster. SOA landing in a way, for example, SOA landing mode are: distributed and centralized service management (ESB), a distributed service-oriented technology has dubbo or spring cloud, etc., must have a comprehensive set of services such as discovery, subscription service , service monitoring, service tracking, service logs and other micro-service basis settings to allow micro-services architecture. Not only simple service call p2p began as a service, that is unrealistic.
3, Service Management
When the service is completed to confirm the split design, and service-oriented infrastructure is put in place, the system will tend to suddenly release all of a sudden out of hundreds of service interfaces, like a network, each service or micro service like a node network, association and connection between each other. However, the service network should be designed as a directed acyclic graph, otherwise, is a mass of hemp. As the beginning, but A calls B, but as the business development, need to change, but do not understand because of A, B will add a link to call A, thus forming a circular calling, not only complex logic, and also reduces the stability and performance.
Service management team here is not about middleware service management, such as overtime optimization, start optimization, etc., but as a platform for application management of the service. Service management is divided into three phases: combing service, service definition and service orchestration. The so-called service carding carding system is opening up service interfaces, including service provider and the consumer, and service groups, such as dynamic routing dependent comb, then break up the service to classify, define, determine service areas from the property, according to field model redefining service boundary, and finally migrate through the service, switching to service interfaces in the same field were integrated services, to provide a unified service exports and achieve service orchestration.
Why should the service governance? Let's look at that service governance without harm.
Micro service would have a resolution of around early copy of the code, the code is not set, will inevitably result in complex diffusion, the same semantic as A, B two interfaces, if the A-interface performance problems need to increase the cache, then the interface B there will still be the same problem, and need the same transformation, so complexity will spread everywhere, but can not achieve a unified service layer framework, and, if the same semantic or interface much like semantics, the interface is confusing , governance can not be achieved limited interface, if the system is a problem, it may be difficult to locate the problem. Business logic is dependent on the data, if the interface is confusing, so slow SQL and other poor quality SQL will not be able to effectively shut transformation, it is more difficult to achieve the same database sharding and decoupling. In summary, the process of service management is the process from disorder to order.
From Split to sum up the service of process, the original is a whole service break, broken into a piece of fragmented services, then the service reclassification, consolidation, forming a field of a new, independent service . Monomers such as architecture is like a magnificent castle, one point if the relative adjustment and transformation, it may face a risk indeed affect the whole body.
It is a series of micro-service small service to support the application of a methodology. Succinctly put, it is: divide and rule.
4, high availability service
After the service and the service of the split, is not it get away, do not! The real micro-services practice has just begun, simply provides an interface, makes no sense, it must have high availability, high performance, high concurrency of three high characteristics, especially high availability is most important. Guaranteed service availability many ways, such as heterogeneous data, multi-level cache, and retry timeout, fuse, asynchronous concurrent, degraded, limiting, message queues, and pressure measurement plans and the like.
Focus on that heterogeneous data, the so-called heterogeneous data, is the order of consumption by the consumer or concurrent manner, subscribe binlog MySQL database, and then through the message, such as Kafka and other MQ way, off-site storage to cache or other data sources, such as Redis, elasticsearch and so on. Heterogeneous data is now commonly used to achieve data aggregation, data forming a closed loop.
Heterogeneous data during the process, the need to focus on a few key points, one CAP principle that strong consistency is often discarded, while the use of eventual consistency of design. Second, caching, caching service in the micro-architecture, can not be used as a silver bullet, using the cache must address issues include: hot & large cache Value cache, cache penetrate other issues. Third message, the message still has problems: a delay problem, the problem of the instability of the message (e.g., message lost), the uncertainty of the message (e.g. timeout), the compensation information, a flexible affairs. These services are highly available micro-architecture practice, can not but face.
5, service isolation
Isolation is also a service that is split, why talk alone? Because the split service, service, service management and service availability in advance or are things you can do, however, some systems have become a way, then we receive, the first can do is quickly on the system isolation, to ensure that does not affect each other business, the specific practices include: process thread isolation, cluster / isolation room, reading and writing isolation, isolation movement, reptiles / hot isolation.
Starting monomers architecture to a distributed architecture, micro-architecture services, to the current domain-driven design, as the architect of micro-services practice, thinking, what changes?
I think programmers are very boring show, but each lived a programmer at heart heroes, Jin Yong "Swordsman" There were gas and Gladius points, what is Gladius, my understanding is like a sword trick, tricks, such as spring, spring boot, spring cloud, as well as tomcat, netty, serviceless, these technologies, middleware, frameworks like scaffolding can help us improve efficiency, but we need the emergence of a new technology on learning a technology? And this reminds me Airbender, it looks like by mastering the internal law, open up Renduermai achieve mastery, as the "Nine Yang magic," he said: He let him strong strong breeze brush hills, I shall infuriating enough. As Kakfa, Flink, Hbase such as partitions to protect the availability of design ideas are based replication strategy BigTable partition.
It is the focus of the transition from outside to inside, so I recognize that, and now the development of the system architecture, a lot of the complexity of the system architecture is not simply through the introduction of new technology or framework, can reduce system complexity. It takes a big early to predict the risks, issues, risks, and to plan ahead. "From scratch learning architecture" mentioned in the book: architecture design is to reduce the software development process is a complex system of course.
"Architecture tidy way" mentioned in the book: the meaning of existence of a software system, is part of the code that the system uses to make money or save money, that is the crown pearl of the entire system. So, when a demand to get the time, the first consideration is to solve the problem, what is its problem domain, not first consider what kind of technology used to achieve or solve this problem, this is the approach of the cart before the horse.
From the perspective of domain-driven design point of view, the problem domain needs first and foremost, what belongs to the business boundaries, to achieve carding understand what features and needs, and then to work in the epitaxial border, confirmed the way of teamwork, because a lot of demand are likely to require cross teamwork, and finally only to the application boundary, that is to solve problems in the field of technology.
The figure is a typical onion model, which describes the idea that thought process from the inside out. Then, the real work, often someone from outside to inside to consider the issue, from my past experience, for example, once data is heterogeneous solution is to use before the Storm, flink later became popular, I will switch to flink business, but for tuning the flink is not in place, thus affecting the stability of the system, and once before with solr searching, and later became popular es, es like to cut, but the search results sorted es and two solr search engine is not the same Finally, we can only raped business. In fact, this is not quite right. "Architecture tidy way" also mentioned: good architecture should be designed to allow the user to defer as much as possible and decided to postpone any framework, databases, Web services, and other environment-related tools.
Understand driven design, need or problem areas in which it began in the will of a field by field experts and delivery teams together, the output of a unified language and domain knowledge, unified language can be agile Kanban, because a team is composed of products, operations, research and development, test composition and to communicate with each other is based on a unified language, then define the border areas, the distinction between core areas, common areas, support areas, the core area is developed by a core team to support the field of outsourcing can be achieved, by mapping context, confirm bounded context, the final confirmation system application boundary. https://mp.weixin.qq.com/
(Picture from the network)
Using art hexagonal drive architecture design drawing areas bounding a transaction system, the different colors indicate different areas, U / D representative of the upstream and downstream. This figure is not too full, because areas of the business logic is to provide the end services, while combing through the field, you can support many common end. I.e. expressed as a bounded field, end ×××. Finally, each bounded context that is micro-services.
In fact, the micro-service architecture evolution path for each system is different, so the service can not practice micro intact copy things by the book, but according to their business characteristics, reasonable cut, to find a suitable landing program. To sum it up, that is: because of the need to change. Although the path of micro-services is not the same, but the direction is the same. Revisits the history of micro-services architecture evolution, you will find that starting from monomer architecture, split, after the formation of micro-services, but also because such a variety of reasons, many micro-service architecture and carrying out the merger, the field is now designed to drive , I began to re-split. Truly be said: the words of the world trend, long period of division, together for a long time to divide.