Architectural decryption from distributed to microservices: what exactly is a microservice architecture?
Microservice architecture
Microservice architecture is a very popular concept at present, and it is an inevitable result of technological development. Microservice architecture is not a vague and empty term. Its core concepts and architectural principles are real. Although there is no recognized technical standard and draft specification for microservice architecture, there are already some influential open source microservices in the industry. Service architecture platform, architects can choose a suitable microservice architecture platform according to the company's technical strength and combined with the characteristics of the project, and steadily implement the project's microservice transformation or development process.
Microservice architecture overview
Microservice Architecture is one of the most popular architectural terms in the past two years. The famous Martin Flower once described it like this:
"Microservices" is just a new term in the software architecture flooding the streets. Although we despise such terms very much, the software style they describe has attracted our attention more and more. In the past few years, we have found that more and more projects have begun to use this style, so that our colleagues take it for granted that this is a default development form when building enterprise-level applications. Unfortunately, it is difficult to find a theoretical description of what the microservice style is and how it should be developed.
In the Internet age, there are new requirements to be developed and launched every day under extreme circumstances. With the increase of the amount of code and team members, the disadvantages of traditional monolithic architecture have become increasingly prominent, which severely restricts the rapid innovation and agile delivery of business, and is farther and farther away from the goal of "only fast but not broken" pursued by the Internet. This is the background of the era of the rise of microservice architecture.
Reasons for the rise of microservice architecture
Why is the microservice architecture rapidly popular? Why do more and more people think that the microservice architecture is a default form of development?
In order to understand the above two questions, we need to understand the other two basic questions first, that is, what kind of architecture is the monolithic architecture we usually talk about? What kind of architecture is the microservice architecture? The following figure shows two The difference between the people.
The traditional application architecture is also known as the monolithic architecture, which shows that the various modules of the business system are tightly coupled. Each module runs in a process. Basically, the entire application process must be restarted every time the system is upgraded. If a certain module has a problem, it may cause the entire system to fail to start normally. The microservice architecture is to split the different modules in the business system in the form of microservices, so that each microservice becomes an independent Project, independently compiled and deployed as an independent process, each microservice Services can be deployed as multiple independent processes to provide external services. The external interface is usually REST or RPC. Different microservice processes can also be deployed to multiple servers.
Through the comparison, we will find that the microservice architecture decomposes a huge single process into multiple independent micro processes, and uses a distributed idea to cleverly solve the various problems encountered by the traditional single architecture in the Internet era. Therefore, there are profound reasons why the new concept of microservice architecture has been quickly accepted by everyone and quickly became popular.
In order to solve the challenges faced by the traditional monolithic architecture, the software architecture has evolved into an SOA architecture, an RPC architecture, a distributed service architecture, and finally a microservice architecture. But we need to keep in mind that there has never been a silver bullet in software development, so the micro-service architecture is not a silver bullet, it is more of a change in architectural thinking and development mode, and there are still a lot of technologies in the specific implementation process. Problems and team issues need to be properly resolved.
One of the biggest technical problems faced in the implementation of the microservice architecture is the automation of the development, operation and maintenance process. If we want to transform the original medium-scale system architecture into a microservice architecture, at least a dozen microservices can be split, so the compilation, deployment, commissioning, and upgrade of so many microservice processes will evolve into- A huge project, if there is no automated means, microservices cannot be promoted. When it comes to automation, we have to mention container technology, which is an important driving force for the development of microservice architecture and an important reason for the rapid popularity of microservice architecture.
I have to mention container technology
In fact, container technology has been widely used by some Internet companies for a long time. As early as more than ten years before the rise of Docker, Google has been using container technology to support the world's largest distributed cluster, but it has kept secrets to the outside world until the micro Service architecture tool Kubernets. Google open sourced this technology because container technology has been recognized by the industry as the most important platform-level technology in the IT industry. If it cannot seize the opportunity and control the right to speak, it will gradually lose the market share brought by technological leadership.
Let's review the history of Docker's development first. Docker only released version 1.0 in 2014 and became one of the hottest technologies in 2014. From the B round of financing at the beginning of 2004 to the DockerCon Europe conference at the end of the year, Docker has had a smooth run this year, and even Microsoft, Google, and AWS also favored it. At that time, microservice architecture, cloud computing, Technical concepts such as DevOps are in full swing, and Docker has perfectly driven the implementation of these concepts technically. In 2015, CoreOS released its own container engine Rocket, which triggered a big debate about the division and unification of container technology. Then, under the intervention of the Linux Foundation, Docker and CoreOS shook hands and established 0CI (Open Container Initiative). The Standards Committee, which is similar to the JCP organization of Java at the time, participants include giants such as Google and RedHat, and the OCI organization is responsible for formulating container technical standards and specifications. Docker 1.11, released in 2016, became the first container engine that conforms to the OCI standard. From 2014 to 2016, the number of downloads of DockerHub increased from 100 million to 6 billion! In 2017, the Docker company divided the Docker version into an enterprise version and a community version, and began charging for enterprises, and then migrated the code of the Docker open source project to the new Moby project, which was pushed to the community for maintenance. Docker company provides two products, of which Docker-ce is a free container product based on the Moby project, and Docker-ee is its commercial product. We know that there are many steps in the software development process that rely on manual labor, such as setting up the environment, publishing the installation package (publishing the installation package to an FTP server or copying it with a USB flash drive), deploying applications, upgrading the system, etc. Both are time-consuming and labor-intensive, and it is difficult to guarantee the quality and completion time of the task. In a distributed system, once the cluster is scaled up, the above manual operations are extremely easy to cause various errors that are difficult to troubleshoot due to a large amount of repetitive labor. Docker is keenly aware of the above-mentioned pain points in traditional software development, using innovative standardized image (Docker Image) packaging and publishing application technology as a breakthrough, and successfully defined a new standard of "standardization and automation in the software life cycle". The following figure shows a schematic diagram of Docker's standardized image.
The Docker image is an "All in one" hierarchical compression package that contains all dependent files of the target program. You can think of it as a most streamlined virtual machine without a Linux kernel but with a Linux file system and basic commands. This virtual machine includes the installed and configured target application binary code, as well as all other dependent packages in the running target program. For example, a Docker image of a complete application running in Torncat is composed as follows.
The process of starting the image is to start the target program specified when the image is packaged and made. For example, for Tomcat, it is to run the tomcat.sh command. In addition, since the image itself has solidified the installation process and configuration parameters, creating and starting a container through the Docker image has become a very simple and error-free command:
docker. run xxximageThe parameters that need to be specified during operation can be passed to the container through environment variables and startup command parameters. Different containers are isolated from each other, and containers of different image versions can be started on the same host at the same time and the information can be tested. Furthermore, Docker will build images, create containers, and start, stop, suspend, resume, and destroy all the functions of the container into a RESTAPI, so we can realize automatic control through programming, as mentioned later Kubernetes uses Docker's API to implement a fully automated microservice architecture platform.
Can the packaged Docker image be version managed like source code, centrally hosted, and downloaded and run by any networked machine around the world? Docker's second idea imitated GitHub's approach and created the world's only open Docker warehouse A Docker Hub, any organization or individual can register an account and share their own packaged Docker image. Now almost any middleware or basic application you can think of is mirrored on Docker Hub. For example, the following command will automatically Pull down from DockerHub-a MySQL mirror, and start a MySQL server on this machine, which can be accessed by remote machines. The existence of DockerHub has greatly accelerated the popularization and development of Docker technology.
docker run -it -e MYSQL_ ROOT PASSWORD=123456
mysql/mysql-serverThe private mirror repository is called the Docker Registry. Usually, every company that uses Docker needs to establish a private Docker Regitry to store standard basic images pulled from Docker Hub and private images packaged based on these basic images. The following figure shows the interaction process with Docker Registry during Docker image packaging and running.
In summary, through Docker technology, we can easily automate all important links in the life cycle of software development from source code compilation, image packaging, test environment deployment, version release, system upgrade to production environment release, etc. This is to accelerate micro An important technical guarantee for the implementation of the service architecture. The following figure is a simple schematic diagram of this process.
How to fully understand the microservice architecture
The microservice architecture evolved from the SOA architecture, RPC architecture, and distributed service architecture. It also has the following characteristics.
First of all, the microservice architecture is a distributed system architecture. That is to say, the principles and experience of distributed system design, as well as the commonly used distributed infrastructure and middleware are still important parts of the microservice architecture. If these technologies in the distributed architecture are aside, just talk about the microservice architecture. , It is like a castle in the sky.
Secondly, like the SOA architecture, the microservice architecture has nothing to do with the development language. It does not have a recognized technical standard specification and implementation plan. It more reflects a generally accepted new design concept and guiding ideology, and summarizes it There are the following points.
●Lightweight services: Each service instance only provides one or several closely related services, with small granularity and light weight, which facilitates the rapid development, deployment, testing and upgrade of the micro team.
●Loosely coupled system: The call between microservices is also a call method of the client, which is limited to the coupling of the interface layer, avoiding the deep coupling of the service realization layer, so the dependency between services is minimized, and the system's The overall stability and balance upgrade (rolling upgrade) capabilities are effectively guaranteed.
●Smooth expansion capability: Because a certain microservice load balancing mechanism is natively provided in the microservice architecture platform, for stateless microservices, the overall throughput can be improved by independently deploying multiple service process instances. Since each microservice can be individually expanded, the microservice architecture has strong runtime performance tuning capabilities.
Building-block system: Each microservice is usually designed as a logical unit (building block) with the smallest granularity in a complex business process. A complete business process is a workflow formed by rationally arranging (building blocks) these microservices. , Upgrading or re-developing a new business process has become a simple building block game. With more and more microservices, the reuse value of business units (microservices) is increasing, so new businesses are quickly launched The demand becomes a planned task that can be accurately assessed and predicted.
Finally, the microservice architecture also has some de facto recognized frameworks and tools, the most classic at present are the following three microservice architecture open source platforms.
- The IceGrid microservice architecture platform evolved from the RPC architecture.
- The Spring Cloud microservice architecture platform evolved based on the REST interface.
- Kubernetes microservice architecture platform based on container technology.
The above three classic microservice architecture platforms can provide complete microservice architecture and management tools, each with its own advantages in technology. Overall, Google’s Kubermetes is an excellent microservice architecture, which is also the focus of this chapter. Microservice architecture.
Next, let's take a look at the problems and coping strategies that may be encountered in the process of implementing a microservice architecture project.
First of all, the architect needs to train all members of the project team to let everyone understand the ideas and advantages of the microservice architecture. An important goal of the training is to let everyone understand that the microservice architecture will bring a lot to the project team during the implementation process. Obvious skill upgrade needs, whether it is for developers or operation and maintenance testers, this is a rare opportunity to learn new technologies and improve self-skills. I hope everyone can withstand the pressure to complete the project.
Secondly, we must correctly choose a suitable microservice architecture platform instead of researching and developing it ourselves. This kind of large-scale basic platform has high research and development costs, a long development cycle, and the possibility of sustainable platform upgrades. Therefore, few companies currently conduct research and development on their own, even if it is a powerful and experienced open source software service-type such as RedHat The company also gave up its own microservice architecture and switched to Kubernetes. So, how do you choose a microservice architecture platform suitable for your company and project team? Take the three typical microservice architecture platforms mentioned in this section as an example, you can refer to the following conditions for selection.
●If the entire team has no experience with container technology, exclude Kubermnetes, otherwise choose it first.
●If the performance requirements of the system are very high, and at the same time there are a large number of microservice calls in many high-frequency processes, and there are also a large number of calls between microservices, first consider the microservice platform that communicates in RPC binary mode, first consider Ice, and then It's Kubernetes, and finally Spring Cloud.
●If the system is more remote calls between various services developed internally, middleware is rarely used, and only high-performance communication and horizontal expansion capabilities are required, then Ice may be the best choice, followed by Spring Cloud , Finally, Kubernetes. Because Kubernetes does not provide an RPC architecture, in this case, it increases the complexity of the system.
●If the project is developed collaboratively in multiple languages, in this case, Kubernetes architecture and Ice can be preferred.
Furthermore, the following tasks are often considered during the implementation of a microservice architecture project.
(1) Introduce automation tools and centralized operation and maintenance management tools. Automated tools are used in the process of program compilation and packaging, automated deployment and upgrades. The centralized operation and maintenance monitoring tools mainly include log collection and query display systems, which are used to collect system logs and application logs distributed on various nodes, as well as resource monitoring and fault systems, which are used to display resource usage status and application alarms.
(2) Research and evaluate a large number of related open source products (and tools) and introduce them into the microservice architecture. The microservice architecture is essentially a distributed architecture, so some general code written in the development of the monolithic architecture cannot be applied to the microservice architecture system, such as the most common configuration modules, timing tasks, and synchronization logic. Wait. In addition, for many middlewares, they may only use a single-node method originally, but under the microservice architecture, they often need to switch to a cluster mode. In this case, more in-depth research and testing of these middlewares are needed. , And may even switch to other similar middleware.
(3) Reconstruction of the team. In the microservice mode, the entire system is basically divided into the presentation layer and the microservice layer from the perspective of the architecture layer.
Considering the importance of microservices in the entire system, it is recommended that the backbone technicians in the team become the main force in the development of the microservice layer. As a whole, they are responsible for all microservice codes, and design each microservice interface together. Review all microservice codes, and in the specific development process, several microservice modules with higher similarity can be handed over to the same person for research and development. This model basically conforms to the 28th law.
(4) High-quality documents. Under the microservice architecture, the importance of documentation, especially the interface documentation of each microservice, is getting higher and higher, because everyone who uses microservices must know which microservice is currently being called, which interface and parameters should be called What is the meaning, and the meaning of the return value. Therefore, we need a detailed and accurate microservice interface document, and also, to keep the document and code updated synchronously.
Next, let's look at how to design microservices in the system. At the beginning, we were actually not very clear about what functions and services should be designed as a microservice, how many interfaces a microservice should include, and how each interface should be designed. The author's suggestion is to divide microservices in a coarse-grained manner. Each microservice includes more interfaces to reduce the number of microservices. This can reduce the workload of development, program packaging, testing, and deployment, which is conducive to rapid project advancement.
Microservices in the system can be divided into three types: process control, interface, and basic core classes, as shown in the figure below.
Generally speaking, the interface designs of these three different microservices are also different.
Process control microservices are mainly oriented to UI calls, so its interface design should take the convenience of page display as the first goal, that is, in most cases, use JSON or TEXT text to pass parameters and return values, and consider calling logic In the event of an error, tell the client the error code and reason, so the return value of this type of microservice will usually be the following structure:
public class CallResult
int resultCode; //返回代码， 0为成功，其他为调用错误
String resultData;//调用结果， 通常为JSON的字符串
String errmsg; //调用错误的时候，展示给用户的可读错误信息Interface microservices are mainly oriented to third-party systems, so special attention should be paid to security issues. Therefore, security measures must be taken in interface design. A common solution is to add Tokens to the call parameters and consider the issue of parameter encryption. At the same time, interface classes are recommended. Microservices pay attention to log output issues in the implementation process to facilitate interface joint debugging and to facilitate interface troubleshooting during operation. Important information such as entry parameters, key logic branches, and return results should be recorded in the log.
The basic core microservices are mainly called by UI and other two kinds of microservices. In the interface design of this kind of microservices, the efficiency and convenience of calling are mainly considered. It is recommended to design it to look the same as the interface of ordinary Java classes, so as to avoid using many complex Bean objects as parameters and return values, which not only increases the burden on the caller but also reduces the interface performance.
In the design of microservices, we also need to consider the issue of interface compatibility, such as the following microservice interface design:
public void doBusiness (paraml, param2, param3)If there is a possibility of increasing the number of parameters, in order to be compatible with the old version, it is best to change to the following design:
public class XXXBean
{
private String paraml;
private String param2;
private String param3;
private String param4;
}
public void doBusiness (XXXBean thebean)In this way, there is no need to recompile the old interface, just upgrade the JAR file where XXXBean is located to be compatible with the old version.