This article is the first in a series of articles on Choerodon’s microservices. In this article, we will introduce two popular microservices architectures, Dubbo and Spring Cloud, and summarize some practical experiences of Choerodon’s microservices architecture. Hope to give you some lessons and enlightenment.

The main content of the article includes:

  • What is microservices Architecture
  • The background of Dubbo
  • Spring Cloud comes into being
  • Kubernetes + Docker makes microservices implementation possible
  • Microservices “new kid on the road” — Service Mesh

When Choerodon started, we wanted to develop an enterprise-level PaaS platform based on container technology, integrating the DevOps tool chain and microservices application framework to help enterprises achieve agile application delivery and automated operations 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 and use the extension mechanism of open source tools to build the platform, to create an open technology platform and system, so that enterprises can enjoy the achievements of the open source community.

Of course, Rome wasn’t built in a day. In addition to the practice and iteration of the specific application of the Choerodon Platform, the technology stack of the platform has been continuously iterated since the initial determination of the technology stack. There are many open source technologies in the open source community to solve the same problem, and how to verify and identify which open source technologies can both meet the needs of the system today and have better adaptability in the future poses a challenge to the majority of architects and software designers. Based on Choerodon’s experience with the toothfish, there are several aspects to consider when using open source technology:

  • Language – One of the core considerations in choosing open source technologies is to use widely used development technologies and avoid involving relatively new technologies and development languages, which can reduce costs for further development. Java, for example, is widely used.
  • Maturity – Whether an open source technology has been released in a stable or higher version 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 your product is still in incubation, there is a higher risk of technical changes, such as Apache incubating, version 0.xxx or beta, which may have various technical bugs or have not been validated.
  • Community – The active degree of open source community reflects the vitality of the whole technology to a certain extent. For example, whether there are a large number of relevant communities, K8s has Kubernetes Chinese community in China, K8s Chinese community, etc., and there are various regular meetings or forums about K8s. Of course the number of stars on GitHub is a reference, as is the number of contributors, the frequency of code updates, etc.
  • Ecosystem – about whether open source technologies have active healthy ecosystem, whether to have more users in the use of, especially some big companies, as well as the surrounding open source products have more articles, knowledge sharing, a function around a product or a third party strengthen the open source tools, such as around Hadoop Sqoop, Hbase, Hive, etc.
  • Documentation – Complete and timely updated documentation, which is very helpful for users to understand the design ideas, installation, use of open source products, and facilitate the implementation of products on the user side. Consider sourceForge.net is now a code graveyard, and code without documentation usually has a short life cycle.
  • Resources – If the open source technology is relatively popular in the industry, there should be more users, and the relevant personnel resources in the market are also very rich, which is conducive to the complement of team technical personnel.

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

What is microservices Architecture

Before we begin, we need to understand what microservices architecture is. In early 2014 (the year of Microservices), Martin Fowler, the father of Microservices, published “Microservices” on his blog, in which he formally proposed the style of Microservices architecture and pointed out some features of Microservices architecture.

To put it simply, microservices are a design style of system architecture that aims to break up a previously independent system into small services that run in separate processes and communicate and collaborate with each other through RESTful apis based on HTTP. Each small service being split is built around one or more well-coupled business functions in the system, and each service maintains its own data storage, business development, automated test cases, and independent deployment mechanisms. With a lightweight communication collaboration foundation, these microservices can be written in different languages. — 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 and front-end display. In the early stage of business development, it is easier to develop, test and deploy all the business logic in one application. However, with the development of business, the system will constantly add different business modules for single applications to meet different business requirements. Over time, the continuous expansion of business requirements led to the single application system is getting bigger and bigger. At this time, the problems of single applications also gradually emerge. Because single applications are a “whole”, they often modify a small function, which will affect the operation of other functions in order to deploy online. In addition, for services, different modules have different requirements on system resources, and each functional module of a single application cannot be separated, so the requirements on system resources cannot be refined. Therefore, a single application is convenient and quick in the initial stage, but with the development of the business, the maintenance cost will become larger and harder to control.

Martin Fowler believes that the biggest difference between microservice architecture and single application is that microservice architecture divides a complete single application into multiple business services with independent deployment capability, and each service can use different programming languages and storage media to maintain low level of centralized management. The following diagram illustrates the difference between a monolithic architecture and a microservice architecture.

According to Choerodon’s development practice and product transition experience, in the context of Internet +, cloud computing, big data and artificial intelligence, the basic framework of the software system should be built first to facilitate subsequent expansion. The independent deployment and loose coupling features of the microservice shelf are consistent with Choerodon’s ideas and design philosophy, so Choerodon chose the microservice architecture as the infrastructure.

In the microservice infrastructure framework, there are two microservice architectures that have to be mentioned, namely Alibaba’s Dubbo and Pivotal’s Open source Spring Cloud.

The 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 realize the output and input functions of services through high-performance RPC, and the Spring framework can be seamlessly integrated. Essentially, it is a service framework. According to Dubbo’s official Roadmap, Dubbo’s development Roadmap is as follows:

  • Data Access Framework (ORM) : The early mainstream development approach is object-oriented development. Just one application, deploying all functions together to reduce deployment nodes and costs. Relational database is the mainstream data storage system that permanently stores data in the enterprise application environment, which simplifies the workload of adding, deleting, modifying and checking.
  • Web Framework (MVC) : As the number of visits gradually increases, a single application can no longer meet business requirements. The application is divided into several unrelated applications, and the view layer and business logic layer are separated to improve efficiency.
  • Distributed Service Framework (RPC) : With more and more vertical applications, the interaction between applications is inevitable. Services are extracted as independent services, and a stable distributed service architecture is gradually formed.
  • Service-oriented Architecture (SOA) : As services grow and businesses and environments change faster, the need for resource control and performance becomes more important. SOA makes business IT systems more flexible by modularizing the business logic of an application or some individual function and presenting IT as a service to consumers or clients.

Dubbo laid out our system in layers, with three core parts: remote communication, cluster fault tolerance, and automatic discovery. Provide transparent remote method invocation, decouple services from each other, and implement service invocation through RPC invocation.

Due to its own design, Dubbo makes the invocation between services more transparent and consumes less network. Meanwhile, it realizes service registration with distributed coordination services like ZooKeeper. But Dubbo’s shortcomings are also obvious, such as:

  • Supporting only JAVA limits Dubbo’s development language
  • Although RPC has higher performance than HTTP, it has limitations in network universality
  • In addition, for a microservice architecture, including service gateway, configuration center and many other things are missing and need to be implemented by themselves
  • Although Dubbo was open source early on, there was no official maintenance of the open source version for a long time

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

Spring Cloud comes into being

After the concept of micro-service architecture was put forward, Netflix soon abstracted and implemented its own micro-service architecture verified by years of mass production into a set of open source micro-service basic components, NetflixOSS. In 2015, Pivotal integrated NetflixOSS open source microservices components into its Spring infrastructure and launched the Spring Cloud microservices development stack. Since then, microservices technology has become so popular that Spring Cloud has become synonymous with microservices.

Perhaps more readers who know about microservices architecture are starting from Spring Cloud. With the good mass foundation of Spring Framework and the fashionable name of Cloud, the name of Spring Cloud can be said to be known by everyone. Combined with Spring Boot from Pivotal, we can easily and quickly implement a microservice framework by encapsulating mature open source Spring Cloud components and some basic distributed infrastructure services, lowering the threshold of application microservitization.

Spring Cloud offers a whole set of solutions for microservices 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 set of microservices built with Spring Cloud.

As you can see, The integration of many components in Spring Cloud reduces the technical architecture requirements for large-scale system construction, enabling architects to build an efficient, distributed, and fault-tolerant platform at very low cost (technical or hardware). At the same time, however, some problems with Spring Cloud have been found in actual development:

  • High technical requirements: Spring Cloud does not provide a mature component for basic functions such as configuration center, fuse downgrading, distributed tracking, authorization authentication, and distributed things. It needs to combine third-party components or self-developed implementations. This puts very high technical demands on the entire development team.
  • Highly intrusive code: Spring Cloud is somewhat intrusive to business code, and the cost of technology upgrade and replacement is high, resulting in low willingness of implementation team to cooperate and difficulty in micro-service implementation.
  • Service operation and maintenance difficulties: Spring Cloud still has deficiencies in service scheduling and deployment, service logging, service monitoring, etc. As the service scale increases, the management of microservices may increase the burden of operation and maintenance.
  • Insufficient multi-language support: For large companies, especially the rapidly developing Internet companies, the nature of the enterprise determines that multi-language technology stack and cross-language service invocation are also normal, and cross-language service invocation is exactly one of the important features to be realized at the beginning of the concept of micro-services.

Dubbo vs. Spring Cloud

A comparison between Dubbo and Spring Cloud shows that Dubbo only implements service governance, while Spring Cloud’s sub-projects separately cover many components of the microservices architecture, of which service governance is only one aspect.

According to the search statistics of Google and Baidu, Spring Cloud search index in China has gradually overtaken Dubbo since 2015.

Overall, Dubbo focuses on service governance; Spring Cloud focuses on the microservice architecture ecosystem.

While Spring Cloud has lowered the bar for microservitization, the Choerodon team has faced a number of practical development challenges in addition to basic service discovery. For example, each component is not perfect, and many components have many deficiencies and defects in practical application. Spring Cloud is not a silver bullet. The microservice architecture solves the problems that are difficult to maintain after the single system becomes huge and bloated. However, the separation of services also causes many problems that are not existing in the single application, such as difficult deployment, difficult monitoring and high operation and maintenance costs. Are the first issues to face when choosing Spring Cloud.

The popularization of containerization, especially the continuous improvement of cloud native technology ecology, has better solved many problems caused by the adoption of micro-service architecture, making it possible for micro-service to be implemented in ordinary traditional enterprises.

Kubernetes + Docker makes microservices implementation possible

When enterprises gradually accept microservice architecture and enjoy the benefits of microservice, they also face many problems such as the increase of microservice operation and maintenance cost, inconsistent environment, and service arrangement, deployment and migration. The Choerodon platform has evolved from the initial introduction of Docker, to Rancher + Jenkins, and now to Kubernetes as a container orchestration and management tool.

The main reason for container technology is not waste of resources. The main reason is that the environment of development and operation personnel is inconsistent, which leads to the greatly reduced development efficiency. With the ability of containers to run code very efficiently in a completely isolated environment, containerization is a natural fit for microservices, improving the development efficiency that has been greatly reduced since the introduction of Spring Cloud microservices. However, the use of Docker alone does not completely solve the pain points of micro-service management, and the deployment, operation and maintenance of services still need to be solved.

Kubernetes is a container orchestration engine from Google. It is an open source software based on GoLang implementation. Early K8s (Kubernetes) originates from the inside of the Google, Borg, provides the application oriented container cluster deployment and management system, its target choreography to eliminate the physical/virtual computing, the burden of network and storage infrastructure, and makes the application operators and developers to fully focus on container centered on the primitive self-service operations.

In the early days, K8s was positioned as a container choreography engine, while other popular container choreography engines at the same time included MESOS, Docker Swarm and so on. However, after several years of development, K8s has become the common infrastructure of Cloud providers, we are familiar with Google Cloud, AWS, Microsoft Azure, Ali Cloud, Huawei Cloud and so on, all provide support for K8s. Today, K8s is more of an industry standard for microservices architecture than just a tool.

The figure below looks at K8s through the use of microservices architecture and illustrates some of the capabilities in K8s.

The comparison shows that K8s itself belongs to the category of microservice architecture in terms of design. Some of you may wonder, since K8s is so powerful, which is better, K8s or Spring Cloud? Why doesn’t Choerodon just use Kubernetes as the underlying microservices architecture?

To distinguish the scope of the Spring Cloud and Kubernetes projects, the following chart lists the almost end-to-end microservices architecture requirements, from the underlying hardware to the upper DevOps and self-service experience. It also lists how to relate to the Spring Cloud and Kubernetes platforms.

You can see:

  • Spring Cloud: Top-down, for developers, from application code to microservices architecture
  • Kubernetes: Bottom-up, infrastructure-oriented, trying to solve the problems of microservices at the platform level, shielding developers from complexity

In conclusion, K8s follows the basic core elements of microservices architecture. Although it lacks some features, it is undeniable that K8s helps make up for the lack of Spring Cloud.

Microservices “new kid on the road” –Service Mesh

Choerodon makes it easy to build and deploy microservices architectures by using the Spring Cloud + Kubernetes pattern. But there are still some difficulties when managing an entire microservice system online.

There has always been a fallacy that networks are reliable in distributed systems. In fact, networks are unreliable and insecure, and most of the failures in microservices occur in service communications.

K8s helps us to realize the deployment of micro-services, but the network call, flow limiting, fusing and monitoring of services still make development and operation personnel very headache. How to ensure the security and reliability of application calls and transactions? The Service Mesh was born.

Over the past few months, Service Mesh has been the undisputed focus of the industry. Service Mesh, translated as “Service grid” or “Service grid”, serves as the infrastructure layer for communication between services. Service Mesh is a pattern, not a technology. William Morgan, CEO of Buoyant, wrote WHAT’s A SERVICE MESH? AND WHY DO I NEED ONE? Explains what a Service Mesh is.

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, they need not care about the network layer when writing applications, allowing services to return to their essence and focus on business functions, leaving the interaction of services to the Service Mesh. Service Mesh provides a view of services, improves traceability, and provides the ability to add traceability without touching all applications. This is called Service Mesh code non-intrusion and transparency, which helps teams better manage services.

Service Mesh architecture diagram:


As you can see, the Service Mesh works in a Sidecar mode. Deploy a Sidecar Proxy for each microservice instance. The Sidecar Proxy takes over the inbound and outbound traffic of the corresponding service, and extracts the functions of service subscription, service discovery, fusing, traffic limiting, degradation, and distributed tracing from the micro-service architecture to the Proxy.

Sidecar is started as an independent process. Each host can share the same Sidecar process, or each application can have an exclusive Sidecar process. All service governance functions are taken over by the Sidecar. Applications can access only the Sidecar. When the Sidecar is deployed in a large number of microservices, the Sidecar nodes naturally form a service grid.

These service grids are managed through control side components, thus providing an efficient and unified way to manage microservices. Centralized control panel while still providing freewheeling agility and cloud-based application development. This makes Service Mesh a trend.

Total knot

Reviewing the development of microservice structure in recent years, microservice architecture is gradually popularized, container technology is emerging, Cloud Native trend is emerging, and the ecosystem of microservice technology is constantly changing. New technologies and concepts such as container, Cloud Native, Serverless, Service Mesh, and Knative are emerging one after another. Make the whole ecology with micro service as the core more and more perfect and mature.

As mentioned above, Kubernetes and Service Mesh solve the problems within the system scope of microservice architecture itself. Solid and reliable basic framework is conducive to subsequent development, which is also the key first step of 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. At the beginning of the development of many products, they do not pay much attention to standardization. When the product needs become more and more complex and the number of personnel increases, the whole project will become difficult to maintain and even affect the continuous iteration of the product. Especially the introduction of micro-service technology system, this problem will be more obvious. Therefore, if the project begins with the idea of engineering to organize the code, to do the construction and release in a standardized process, it will lay a solid foundation for the subsequent development. The engineering implementation of microservices has been the focus and practice of Choerodon. By integrating the DevOps tool chain and introducing the methodology of agile implementation on the ground, it makes the engineering implementation of microservices architecture easier. This is also Choerodon’s PaaS platform capability, which will not be described here. Interested readers can check out Choerodon’s website (Choerodon.io).

About the Choerodon toothfish

Choerodon is an open source enterprise services platform that builds on Kubernetes’ container orchestration and management capabilities and integrates DevOps toolchains, microservices and mobile application frameworks to help enterprises achieve agile application delivery and automated operations management. It also provides IoT, payment, data, intelligent insights, enterprise application marketplace and other business components to help enterprises focus on their business and accelerate digital transformation.

You are welcome to learn about the latest developments of toothfish, product characteristics and contribute to the community through the following community channels:

  • Liverpoolfc.tv: choerodon. IO
  • BBS: forum. Choerodon. IO
  • Github：github.com/choerodon/
  • Choerodon Toothfish on wechat
  • The Toothfish Choerodon

Welcome to join the Choerodon Toothfish community to create an open ecological platform for enterprise digital services.

​