I also want to write a micro-service article, as well as the advantages and disadvantages of micro-services _ Architecture

What is Micro Service

First, micro-service is not a name, but an architectural concept, just as restful not only describes the format of the API, but more describes the architecture based on the RESTful API. A micro-service architecture (MSA) is a large system that is dispersed into many small systems through horizontal or vertical, business, or architectural segmentation, for the original large systems. When the system is complex to a certain extent, the efficiency of the common maintenance of a system is very low, and the risk of the problem is very high. This is where the system needs to be split, and the SOA system, which was proposed earlier, coincides with the architecture of the Micro service. The architecture based on the RPC framework (Dubbo, thrift, etc.) that you use now can also be considered as a micro-service. Micro-services so far do not have the exact boundaries and definitions, seemingly many concepts on the computer are not defined boundaries. However, I understand that the communication between the micro-service is HTTP communication, the traditional RPC invocation is not a strict micro-service, because he can not take care of themselves, need to rely on, for example, if an RPC service producer exists, RPC service consumer can be started. So, in the discussion below, I use HTTP communication as a prerequisite for micro services. What are the benefits of micro-service decoupling: for our low-level programmers, the visible benefit is decoupling. I want to implement a function, may not need to be very in-depth understanding of other people's Code, because the programmer, may feel that someone else's code is a slag ([Laugh and Cry]). I can make a new piece of micro service, this service for other functions to provide services, but not dependent on the original features, as to the business logic, you can be on the side of the hands-on familiar with the cohesion, can be deployed independently: means that I maintain this micro-service, can be deployed independently, to other services will not be strong dependence, There will be no issue where my own services do not start or are not available because other services do not exist: micro-service architecture does not exist a particularly large system contains many central functions, which can also improve fault tolerance, a service paralysis does not allow the entire system paralysis permission validation: Micro-service is a highly cohesive service, My own this service, I can customize any reasonable rules, and this rule is only applicable to my own services. Compared to the Dubbo RPC call, the authorization of HTTP micro-service invocation can be more direct and more strict and more customized, while RPC call permission verification, I personally always feel that can not do very elegant data separate governance, with the library properties: The original large system to use a database, when the data a lot of traffic is very large, Will involve the Sub-library table. In the case of micro services, each service uses a database, whether the database is public or self-built with other services has a lot of flexibility, that is, I think the micro-service self-contained sub-table property system will not be permanently limited to a technology stack, under the micro-service architecture, the entire system will not be limited by Java or Nodejs or go,It's all about teamwork and not conflict, all HTTP protocols, JSON format unit testing of various modules is easy to automate and other micro services face the challenge of communication, HTTP request speed is slow, usually one operation may involve multiple micro-service invocation, if in order to complete an operation from the server to invoke different micro-services, The time consuming HTTP requests can be a bottleneck, as shown in Figure 1.
Communication between client and server requires an API GateWay: Typically, clients and micro-services are not together, and each micro-service is centrally deployed in one room, and the invocation of the micro-service is fast, but calls between clients and micro-services can be time-consuming. Also, one of the user's actions cannot be called repeatedly on the client, which is slow and risks leaking the system architecture. Normally, there will be an API GateWay between the client and the micro-service architecture, as Figure 1 shows in Figure 2, the most important role of the GateWay is to provide the client with the aggregation of backend services, provide a unified service outlet, and remove the coupling between them, in order to solve the API Gateway single point of failure or performance bottlenecks, usually gateway is also a cluster, and the Client access control, account management, login management and other sections are usually processed here
A lot of micro-services, the entire link can be very long, the risk of call failure is high, and e2e automation test will become a problem service registration and service discovery, I division has its own service management system. I recommend Etcd. Google's Open-source kubernetes (k8s) seems to be using this too. Distributed transactions, which are a major problem for a micro-service system, may need to be tailored to your system's circumstances and business needs, and I recommend compensating distributed transactions and message-based distributed transactions. (Next time to introduce the common centralized distributed transactions to do)

The next article will talk about what framework or tools we use to quickly build a micro-service system.