Shulou(Shulou.com)06/02 Report--

Because of the sermon of Martin Fowler and Chris Richardson, and the practice of NetFlix and Amazon, the domestic understanding of some basic issues of micro-service is basically the same, but limited by its own single application, we have to think of different ways to micro-service architecture, and we have to look at the specific problems. This article describes the basic concepts of micro-service architecture and some personal understanding. " Micro-service architecture is an architectural model, which advocates dividing a single application into a group of small services, which coordinate and cooperate with each other to provide users with the ultimate value. Each service runs in its own independent process, and the service and the service communicate with each other by a lightweight communication mechanism (usually Restful API based on HTTP). Each service is built around a specific business and can be independently deployed to a production environment, class production environment, and so on. In addition, a unified and centralized service management mechanism should be avoided as far as possible. for a specific service, the appropriate language and tools should be chosen according to the business context. "- Martin Fowler blog

Characteristics and definition of micro-service

Vs microservice architecture for single application

Advantages

1: improve development communication, each service is sufficiently cohesive, small enough to make the code easy to understand

2: service independent testing, deployment, upgrade, release

3: customized DFX, resource utilization, each service can be expanded by x and z respectively, and each service can be deployed to an appropriate hardware server according to its own needs; each service presses 4: you need to select the mode of HA, and select the number of instances to receive services.

5: it is easy to expand the development team, for each service (service) component development team

6: improve fault tolerance (fault isolation). Memory leaks in one service will not paralyze the whole system.

7: with the application of new technologies, the system will not be limited to a certain technology stack for a long time.

Shortcoming

Without silver bullet, micro-services increase the complexity of the system; developers have to deal with the complexity of distributed systems; distributed communication between services; registration and discovery of services; distributed transactions between services; report processing after data isolation; distributed consistency between services; complexity of service management, service choreography; management of different service instances.

Chris Richardson's three-dimensional extended model of microservices:

X-axis, horizontal expansion of service instances to ensure reliability and performance

Y-axis, function expansion, service single responsibility, function independent

Z axis, data partition, data independence, reliability guarantee

Communication problem

The split of micro-services generally brings the problem of IPC communication. The communication mechanism should be complete and reliable, the choice of communication between services should be as simple as possible, and the mode of communication should be divided from two dimensions:

Is the first dimension one-to-one or one-to-many:

One-to-one: each client request has a service instance to respond to.

One-to-many: each client request has multiple service instances to respond to.

The second dimension is whether these are interactive synchronous or asynchronous:

Synchronous mode: client requests require an immediate response from the server and may even be blocked by waiting.

Asynchronous mode: client requests do not block processes, and server responses can be non-immediate.

According to the microservice architecture, there should be only these modes of communication between services. For the consideration of time delay and programming model, AC provides a set of communication mechanism, and the communication between services should be selected according to demand.

Discovery and registration of services

In a general micro-service architecture, there are two layers of API GetWay, one is the external API GetWay for users to access the system, and the other is the internal API GetWay, the API GetWay between the internal services. The problems to be solved by internal API GetWay are service discovery and service registration. From this, we can also see why the way of communication should be as simple as possible. One of the tasks of API GetWay is protocol conversion.

Micro-service may be HA active / standby, it may be LB, how to find a service? There are two ways of thinking: the client discovers (left), the client goes to the registry to query the list of service instances and chooses on its own; the other is the server discovery (right), which adds a LB module, and the client sends the request to LB, and LB selects the service instance according to the load balancing policy.

A typical implementation of the microservice registry:

ETCD: a highly available, distributed, consistent, key-value table for shared configuration and service discovery. Two famous cases include Kubernetes and Cloud Foundry.

ZK: is a widely used service that provides high-performance integration for distributed applications. Apache ZooKeeper, which was originally a subproject of Hadoop, has become a top-level project.

Deployment of microservice architecture

Requirements for deployment of the microservices architecture:

Deployment rate. There are thousands of services in Amazon and NetFlix, and each service has a requirement of continuous deployment. Amazon services are deployed once a second.

Deployment automation, everything has to be automated. IaaS and PaaS solve the automatic deployment of layer I and layer P, micro services have automatic deployment and operation and maintenance tools, and implement Auto-Scaling

Deployment provides the basic mechanism. In order to meet the requirements of distributed deployment, deployment mechanisms generally have resource pooling and service life cycle. Deployment services and service registration are integrated.

Granularity of deployment:

VM: the life cycle of the VM managed by the deployment system, such as the current iDeploy deployment of AC, which splits the AC deployment into the installation, configuration and startup of each VM. This approach is coarse-grained and cannot support the deployment of micro-services (unless a service occupies a VM)

App: manage the life cycle and deployment form of an application. The life cycle is divided into deployment, configuration, startup, upgrade, etc. Deployment forms include master / slave, LB, Daemon, etc.

Container: containers have better isolation and portability than APP

Microservices: general microservices are either APP or Container, but AC is not. Limited by the ONOS architecture, our service is a set of feature

Solutions for MS deployment:

TOSCA: cloud application topology standard, a DSL that describes cloud deployment. Our company mainly promotes a standard. Both PaaS deployment system and MANO use TOSCA.

Kubernetes:Google open source container management system, put forward the concept of Pod/Service/Labels, with ETCD as the center, PaaS developed our cloud deployment platform based on K8S

Mesosphere:DCOS, a data center operating system, implements resource pooling based on mesos and has its own orchestration tools; distributed LAB has made a set of deployment and cluster management system (HASEN) based on the idea of DCOS

Division of micro services

The division of micro-service is mainly to ensure that the function of micro-service is cohesive and the responsibility is single. Generally, the idea and method of DDD (Domain Drive Design) is used to divide micro-services, which is similar to the division of database ER diagram, which constantly decomposes the data to ensure that the relational database meets the requirements of atomicity and redundancy. Of course, the division of micro-services is more complex than that of data tables, and there is no concept of micro-service paradigm, but the idea is consistent. For more information, please refer to the book "Domain driven Design".

Distributed consistency

There are two big ideas: global distributed transactions and event-driven

Distributed transaction is now the idea of AC, in design and development.

Event-driven, ignoring the concept of transaction, each service saves the state of the service at the application level, and the communication between the services is notified by the event mechanism; this method can ensure the independence between micro-services, but leave the problem to the designer of the service; for a specific case of event-driven, see the reference material.

Data isolation problem

Data isolation between microservices can ensure independent upgrade and deployment of services. Data isolation has three dimensions:

Data table level isolation; data tables are independent and have no foreign key relationship

Database-level isolation; different services have different databases

DBMS-level isolation; different services have different database management systems

Generally, it is OK to achieve database-level isolation, and the data exchange between services uses inter-service interfaces.

From monomer to micro-service

Micro-service architecture is a derivative architecture, which is evolved from a single architecture.

Because of the complexity of the micro-service architecture, start-up systems seldom use the micro-service architecture in the first place for the sake of rapid development and rapid verification. In addition, the concept of micro-service is only popular in the past two years, large-scale single applications also see the increasing cost of development and maintenance, there will be the motivation to transform micro-services. Therefore, how to move from monomer to micro-service is a common problem.

Principles from monolithic to micro-service:

Evolve step by step, not all refactoring.

All refactoring brings great cost and risk, and the system will have a long period of instability. Moreover, the final effect will not be very good, it is difficult to think of all the problems in the design. The evolution idea of micro-service architecture should be to build infrastructure step by step and break up micro-services step by step.

Evolutionary suggestions (personal suggestions)

1. Do not add new coupling

Do not have compilation dependencies, such as classes that directly import other modules

Use the communication method recommended by the version, do not use osgiservice, this coupling is still very strong; do not directly access the data tables of other modules

Avoid unnecessary affinity and pay attention to the state between features, such as the two requests for feature A to access feature B are stateful, then the two feature instances have affinity.

two。 Front and rear end separation

The front and rear end businesses are separated, and there is no coupling between the front ends. What can be done by the front end is put on the front end.

3. Independent services are gradually being dismantled

Micro-services with independent functions can be removed step by step, and micro-services with special DFX requirements can also be removed first.

DevOps and Micro Service Architecture

DevOps is a concept put forward in 2009, but it has not been too popular. It was not until 14 years ago, when the container and micro-service architecture was proposed, that DevOps developed rapidly. DevOps is not only a tool chain to realize automation, but also a combination of organization, process and technology. Organizational emphasis on the full stack team, team characteristics, team autonomy; technical access to development and operation and maintenance; process emphasis on end-to-end, visualization, grayscale upgrade, Ahand B testing and so on.

It is not necessary for DevOps,MS, but MS provides the best architectural support for DevOps, and the requirements for organizations and processes are consistent. Therefore, some people call MS the DevOps architecture.

At present, Huawei Cloud has invested heavily in supporting micro-services, taking the lead in supporting the Go language service framework in China! Now, microservices are in full swing to carry out a series of experience activities! Interested friends can check it out! Https://activity.huaweicloud.com/cse/index.html?dfk

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.