Choerodon's microservice road (1): how to take the critical first step

Choerodon's microservice road (1): how to take the critical first step

This article is the first in a series of Choerodon Microservices . In this article, I will introduce two popular microservice architectures, namely Dubbo and Spring Cloud. At the same time, it will summarize Choerodon's choice of microservice architecture. I hope to give you some reference and enlightenment.

The main content of the article includes:

  • What is microservice architecture
  • The birth background of Dubbo
  • Spring Cloud came into being
  • Kubernetes + Docker make microservice implementation possible
  • Microservice "Rookie" Service Mesh

At the beginning of Choerodon's vision, we hope to develop an enterprise-level PaaS platform based on container technology, integrate DevOps tool chain and microservice application framework, to help enterprises achieve agile application delivery and automated operation management. At the same time, it also determined the requirements of the technology stack, that is, to make full use of mainstream mature open source components, use the extension mechanism of open source tools to build a platform, create an open technology platform and system, and allow enterprises to enjoy the results of the open source community.

Of course, Rome was not built in a day. From the initial determination of the technology stack to the present, in addition to the practice and iteration of the specific application of the Choerodon pig tooth fish platform, the technology stack of the platform is also constantly iterating. There are many open source technologies that solve the same problem in the open source community. How to verify and identify which open source technologies can not only meet the current system requirements, but also have better adaptability in the future, is proposed to the majority of architects and software designers. Challenge. According to Choerodon's practical experience, when using open source technology, the following aspects can be considered:

  • Language -A very core consideration when choosing open source technology is to try to use more widely used development technologies and avoid involving relatively new technologies and development languages, so that further research and development can reduce costs. For example, Java is widely used.
  • Maturity -Whether the version of the open source technology has released a stable version or higher is an important indicator of its maturity. For example, Istio released version 1.0 in August, prompting many companies and products to follow up; if the product is still in its incubation stage, The risk of technical changes is relatively high. For example, Apache's incubating, 0.XXX version, or beta version may have various technical defects or have not undergone good actual inspections.
  • Community -The activeness of the open source community reflects the vitality of the entire technology to a certain extent, such as whether there are a large number of related communities. K8s has a Kubernetes Chinese community in China, K8s Chinese community, etc., as well as various Meetups about K8s on a regular basis Or forums, etc.; of course, the number of stars on GitHub is a reference indicator, as well as the number of contributors, code update frequency, etc.
  • Ecosystem -Whether there is an active and healthy ecosystem around open source technology, whether there are more users using it, especially some large companies, and whether there are more articles, knowledge sharing around open source products, or a certain function of the product Third-party enhanced open source tools, such as Sqoop, Hbase, Hive, etc. around Hadoop.
  • Documentation -complete and timely updated documentation, which is very helpful for users to understand the design ideas, installation, and use of open source products, and facilitate the implementation of products on the user's side. Consider that is now the tomb of code, and the life cycle of code without documentation is usually not long.
  • Resources -If open source technology is more popular in the industry, there should be more users, and the relevant personnel resources on the market are also very rich, which is more conducive to the supplement of team technical personnel.

So far, after continuous iteration, Choerodon has gradually formed a microservice technology system with Spring Cloud + Kubernetes as the main body.

What is microservice architecture

Before starting the introduction, you first need to understand what is a microservice architecture? At the beginning of 2014 (that year can be called the first year of microservices), Martin Fowler, the father of microservices , published an article " Microservices " on his blog. The article officially proposed the microservice architecture style and pointed out some of the microservice architecture Features.

Simply put, microservices are a design style in the system architecture. Its main purpose is to split an originally independent system into multiple small services. These small services run in separate processes and pass between services. RESTful API based on HTTP for communication and collaboration. Each small service that is split is built around one or some highly coupled business functions in the system, and each service maintains its own data storage, business development, automated test cases, and independent deployment mechanism. Because of the lightweight communication and collaboration foundation, these microservices can be written in different languages. - Author James Lewis and Martin Fowler, translated from "Spring Cloud Microservices in Action"

In the traditional single application system architecture, it is generally divided into three parts, namely database, service application side and front-end display. In the early stage of business development, since all business logic is in one application, development, testing, and deployment are relatively easy . However, with the development of the business, the system will continue to add different business modules to the single application in order to respond to different business needs. Over time, the ever-expanding business requirements have led to more and more large and bloated single-application systems. At this time, the problem of the monolithic application has gradually emerged. Since the monolithic application is a "whole", a small function is often modified, and the operation of other functions will be affected in order to deploy it online. Moreover, for business, different modules often have different requirements for system resources, and because each functional module of a single application cannot be divided, it is impossible to refine the requirements for system resources. Therefore, a single application is relatively convenient and fast in the initial stage, but as the business develops, the maintenance cost will become larger and more difficult to control.

Martin Fowler believes that the biggest difference between a microservice architecture and a monolithic application is that the microservice architecture splits a complete monolithic application into multiple business services with independent deployment capabilities. Each service can use a different programming language and different Storage media to maintain a low level of centralized management . The following picture illustrates the difference between monolithic architecture and microservice architecture.

According to Choerodon's development practice and productization experience, in the context of Internet +, cloud computing, big data, artificial intelligence, etc., to build software system products, the basic framework of the system must first be set up to facilitate subsequent expansion . The independent deployment, loose coupling and other characteristics of the microservice framework coincide with Choerodon's ideas and design concepts, so Choerodon finally chose the microservice architecture as the infrastructure.

In the basic framework of microservices, there are two microservice architectures that have to be mentioned, namely Alibaba's Dubbo and Pivotal's open source Spring Cloud.

The birth background of Dubbo

Dubbo is a high-performance, Java-based open source RPC framework. Alibaba's open source Dubbo is committed to providing high-performance and transparent RPC remote service invocation solutions, as well as SOA service governance solutions, so that applications can achieve service output and input functions through high-performance RPC, and can be seamlessly integrated with the Spring framework. Essentially, it is a service framework. According to Dubbo's official Roadmap, it can be seen that the development of Dubbo has gone through the following processes:

  • Data Access Framework (ORM) : The early mainstream development method was an object-oriented development method. Only one application is needed to deploy all functions together to reduce deployment nodes and costs. Relational database is a mainstream data storage system that permanently stores data in an enterprise-level application environment, which simplifies the workload of adding, deleting, modifying and checking.
  • Web framework (MVC) : With the increasing number of visits, a single application can no longer meet business needs. Split the application into several unrelated applications, separate the view layer and business logic layer to improve efficiency.
  • Distributed Service Framework (RPC) : When there are more and more vertical applications, interactions between applications are inevitable. Businesses are extracted as independent services, and a stable distributed service architecture is gradually formed.
  • Service-Oriented Architecture (SOA) : As more and more services, business and environment change faster and faster, resource control and performance requirements become more important. SOA modularizes the business logic or some individual functions of an application and presents them to consumers or clients as services, making the business IT system more flexible.

Dubbo plans our system hierarchically, including three core parts: remote communication, cluster fault tolerance, and automatic discovery. Provide transparent remote method invocation, decoupling between various services, and realize the invocation of services through RPC calls.

Due to its own design, Dubbo makes the calls between services more transparent and consumes less network. At the same time, it realizes service registration with the help of distributed coordination services such as zookeeper. But the shortcomings of Dubbo are also obvious, such as:

  • Only supporting JAVA makes Dubbo limited in the development language
  • Although RPC has higher performance than HTTP, it has limitations in network versatility
  • And for a microservice architecture, many things including service gateway, configuration center, etc. are missing, and need to be implemented by yourself
  • Although Dubbo has been open source for a long time, it has not been officially maintained for a long time.

Due to these shortcomings, Choerodon did not choose Dubbo as the basic development framework.

Spring Cloud came into being

After the concept of microservice architecture was put forward, Netflix soon abstracted its own microservice architecture after years of large-scale production to form a complete set of open source microservice basic components NetflixOSS. In 2015, Pivotal integrated the NetflixOSS open source microservice component into its Spring system and launched the Spring Cloud microservice development technology stack. Since then, microservice technology has been rapidly popularized, and even Spring Cloud has once become synonymous with microservices.

Readers who know more about the microservice architecture may all start with Spring Cloud. With the good mass base of the previous Spring Framework and the contemporary name of Cloud, the name of Spring Cloud can be said to be unknown to everyone. Combined with Pivotal's Spring Boot, we can easily and quickly implement a microservice framework by encapsulating the open source and mature Spring Cloud components and some basic distributed basic services, reducing the threshold of application microservices.

Spring Cloud proposes a complete set of solutions for microservice frameworks. include:

  • Service registration discovery: Spring Cloud Eureka
  • Load balancing: Spring Cloud Netflix
  • Service Gateway: Spring Cloud Zuul
  • Configuration management: Spring Cloud Config
  • Service consumption: Spring Cloud Ribbon/Feign
  • Distributed tracking: Spring Cloud Sleuth
  • Service fault tolerance: Spring Cloud Hystrix
  • ...

The following figure illustrates a simple microservice system built with Spring Cloud.

It can be seen that Spring Cloud integrates many components, which reduces the requirements for large-scale system construction from the technical architecture, allowing architects to build an efficient, distributed, and fault-tolerant platform at a very low cost (technology or hardware). But at the same time, some problems with Spring Cloud were also found in actual development:

  • High technical requirements : Spring Cloud does not provide a mature component for basic functions such as configuration center, circuit breaker downgrade, distributed tracing, authorization authentication, and distributed things. It needs to be combined with third-party components or self-developed implementation. This places very high technical requirements on the entire development team.
  • Strong code intrusion : Spring Cloud is somewhat intrusive to business code, and the cost of technology upgrades and replacement is high, which leads to low willingness of the implementation team to cooperate and difficulty in landing microservices.
  • Difficulty in service operation and maintenance : Spring Cloud still has shortcomings in service scheduling and deployment, service logs, and service monitoring. When the scale of services increases, the management of microservices may increase the burden of operation and maintenance.
  • Insufficient multi-language support : For large companies, especially fast-growing Internet companies, the nature of the company determines that multi-language technology stacks and cross-language service calls are also the norm. Cross-language calls are also the beginning of the concept of microservices. One of the important features to be achieved.

Dubbo & Spring Cloud comparison

Comparing Dubbo and Spring Cloud, it can be found that Dubbo only implements service governance, while Spring Cloud's sub-projects cover many components under the microservice architecture, and service governance is only one aspect of it.

From the search statistics of Google and Baidu, we can see that since 2015, the domestic search index for Spring Cloud has gradually surpassed Dubbo.

In summary , Dubbo focuses on service governance; Spring Cloud focuses on the microservice architecture ecology.

Although Spring Cloud lowered the threshold of microservices, in addition to basic service discovery, the Choerodon team also encountered many challenges in actual development. For example, each component is not perfect, and many components have many shortcomings and defects in practical applications. Spring Cloud is not a silver bullet. The microservice architecture solves the problem of difficulty in maintaining the monolithic system after it becomes large and bloated. However, because of the service splitting, it has caused many problems that were not originally found in monolithic applications, such as deployment difficulties. , The difficulty of monitoring and the high cost of operation and maintenance are the first problems to face when choosing Spring Cloud.

The popularity of containerization, especially the continuous improvement of the cloud-native technology ecosystem, has better solved many problems caused by the adoption of microservice architecture, making it possible for the implementation of microservices in ordinary traditional enterprises.

Kubernetes + Docker make microservice implementation possible

When enterprises gradually accept the microservice architecture and enjoy the benefits of microservices, they also face the increase in microservice operation and maintenance costs, inconsistent environments, and service scheduling, deployment, and migration. The Choerodon platform has undergone continuous evolution, from the initial introduction of Docker, to Rancher + Jenkins, and now using Kubernetes as a container orchestration and management tool.

The main reason for container technology is not a waste of resources. The main reason is that the environment of development and operation and maintenance personnel is inconsistent, which greatly reduces development efficiency. Through containers, code can be run very efficiently in a completely isolated environment. Containerization is naturally suitable for microservices, which improves the problem of greatly reducing development efficiency after the introduction of Spring Cloud microservices. However, the use of Docker alone does not completely solve the pain points of microservice management. Service deployment and operation and maintenance still need to be solved urgently.

Kubernetes is a container orchestration engine launched by Google and an open source software based on GoLang. K8s (Kubernetes) originated from Google s internal Borg and provides an application-oriented container cluster deployment and management system. Its goal is to eliminate the burden of orchestrating physical/virtual computing, network and storage infrastructure, and to enable application operators and Developers are completely focused on self-service operations on container-centric primitives.

In the early days, everyone positioned K8s as a container orchestration engine. In the same period, popular container orchestration engines included MEOS, Docker Swarm, etc. However, after several years of development, K8s has become a common infrastructure for cloud providers. Google Cloud, AWS, Microsoft Azure, Alibaba Cloud, Huawei Cloud, etc. that we are familiar with all provide support for K8s. Now, K8s is not only a tool, but also an industry standard for microservice architecture.

The following figure looks at K8s by using the design idea of microservice architecture, and explains some of the functions in K8s.

Through comparison, it can be seen that in terms of design, K8s itself belongs to the category of microservice architecture. Some people here may have questions. Since K8s is so powerful, which one is better, K8s or Spring Cloud? Why doesn't Choerodon directly use Kubernetes as the basic microservice architecture?

In order to distinguish the scope of the Spring Cloud and Kubernetes projects, the following figure lists the almost end-to-end microservice architecture requirements, from the underlying hardware to the upper-level DevOps and self-service experience, and lists how to connect to Spring Cloud and Kubernetes platforms.

can be seen:

  • Spring Cloud: Top-down, for developers, from application code to all aspects of microservice architecture
  • Kubernetes: bottom-up, infrastructure-oriented, trying to solve the problem of microservices at the platform layer, shielding developers from complexity

In summary, K8s follows the basic core elements of the microservice architecture. Although some functions are lacking, it is undeniable that K8s helps make up for the missing part of using Spring Cloud.

Microservice "Rookie"--Service Mesh

Choerodon helps us build and deploy microservice architecture easily by using the Spring Cloud + Kubernetes model. However, when managing the entire microservice system online, there are still some difficulties.

There has always been a fallacy, that is, the network is reliable in a distributed system. In fact, the network is unreliable and insecure. Most of the faults in microservices occur in service communication.

K8s helped us realize the deployment of microservices, but the problems of network calling, current limiting, fusing, and monitoring of the service still caused great headaches for developers and operation and maintenance personnel. How to ensure the security and reliability of application calls and transactions? Service Mesh came into being.

In the past few months, Service Mesh has been the undisputed focus of the industry. Service Mesh is translated as "service grid" or "service grid" and serves as the infrastructure layer for communication between services . Service Mesh is a pattern, not a technology. Willian Morgan, CEO of Buoyant , explained what a Service Mesh is in his article "WHAT'S A SERVICE MESH? AND WHY DO I NEED ONE?" .

A service mesh is a dedicated infrastructure layer for handling service-to-service communication It's responsible for the reliable delivery of requests through the complex topology of services that comprise a modern, cloud native application. In practice, the service mesh is typically implemented as an array of lightweight network proxies that are deployed alongside application code, without the application needing to be aware.*

Service Mesh is essentially a lightweight network proxy, like TCP/IP between applications or microservices.

For developers, there is no need to care about the network layer when writing applications, so that the service returns to the essence, focusing on business functions, and the interaction in the service is handed over to the Service Mesh. Service Mesh provides a view of services, improves tracking capabilities, and provides the ability to add tracking without touching all applications. The so-called Service Mesh code is non-invasive and transparent, which can help teams better manage services.

Service Mesh architecture diagram:

As you can see, Service Mesh adopts a Sidecar model. Deploy a Sidecar Proxy to each microservice instance. The Sidecar Proxy is responsible for taking over the inbound and outbound traffic of the corresponding service, and extracts the service subscription, service discovery, fuse, current limit, downgrade, distributed tracking and other functions in the microservice architecture from the service to the Proxy.

Sidecar is started as a separate process, and each host can share the same Sidecar process, or each application can have an exclusive Sidecar process. All service management functions are taken over by Sidecar, and the external access of the application only needs to visit Sidecar. When the Sidecar is deployed in a large number of microservices, these Sidecar nodes naturally form a service grid.

These service grids are managed through control plane components, which provides an efficient and unified management method for microservices. A centralized control panel, while still having the agility and cloud-based application development you want. This feature makes Service Mesh a general trend.


Looking back on the development of microservice structure in the past few years, the gradual popularization of microservice architecture, the rise of container technology, the trend of cloud native, microservice technology ecology is constantly changing, container, Cloud Native, Serverless, Service Mesh, Knative, etc. The new technology concept is yours and I will appear on the stage, making the entire ecosystem centered on microservices more and more mature.

As mentioned in the previous article, Kubernetes, Service Mesh, etc. are all to solve the system-wide problems of the microservice architecture itself. A solid and reliable basic framework is conducive to subsequent development. This is also a key first step in product development and system implementation .

In addition to the technology stack of the system itself, the implementation of the project is another problem to be solved. When many products are developed, they don t pay much attention to standardization. When product requirements become more and more complex and there are more and more people, the entire project will become difficult to maintain, and it will even affect the continuous iteration of the product. Especially with the introduction of the microservice technology system, this problem will be more obvious . Therefore, if the project starts with an engineering idea to organize the code, and a standardized process to build and release, it will lay a solid foundation for subsequent development. The project implementation of microservices is the direction that Choerodon has been paying attention to and practice. By integrating the DevOps tool chain and introducing the methodology of agile implementation, the project implementation of the microservice architecture has become easier. This has also become Choerodon's PaaS platform. Ability, I won t go into details here, and interested readers can go to Choerodon s official website ( ).

About Choerodon Hogtooth

Choerodon is an open source enterprise service platform. It is an open source platform based on Kubernetes-based container orchestration and management capabilities that integrates DevOps toolchain, microservices and mobile application frameworks to help enterprises achieve agile application delivery and automated operation management. At the same time, it provides business components such as IoT, payment, data, intelligent insights, and enterprise application markets, and is committed to helping companies focus on business and accelerate digital transformation.

Everyone is welcome to learn about the latest developments, product features, and participate in community contributions through the following community channels:

Welcome to join the Choerodon pig tooth fish community and jointly create an open ecological platform for enterprise digital services.