One, foreword

In order to implement products based on microservices development, or in order to restructure individual applications into microservices architecture, there are many technical frameworks to choose from. Large companies often have a dedicated department or team responsible for developing their own frameworks to meet product needs, but for the average small and medium enterprise, choosing the right open source framework is more relevant. This chapter will briefly introduce what principles should be paid attention to when selecting technology in micro-services and some commonly used open source technical frameworks, hoping to provide some ideas and directions for technology selection and research.

I’ve interviewed a lot of programmers, and when you mention microservices, you’ll be talking about Spring Boot, Spring Cloud, and then reciting the various usage and configuration files. This is not to say that this is wrong, but we would like to know more about how these technical frameworks work, why they were chosen, and how they differ from other similar frameworks.

As to how to use a technical framework, it applies to any scenario, the author suggested that can be directly read the documentation on the official or the corresponding lot, have need can also read the concerns of the source code, this to the correct understanding of it, it is necessary, after all official things are relative to the authority, the maturation may exist in other parts of the data, Use to everybody, understanding existence certain misdirect. (This is just some suggestions for you to consult the data when selecting the technology.)

Two, selection principle

In the field of software development, new technical frameworks are born and updated almost every day, and some new concepts emerge in endlessly. For technology selection, I personally have the following suggestions:

1. If there is a demand, introduce it again

In a microservices architecture, there are many different types of components/technologies, but that doesn’t mean all of them should be included in your project, and it would be unwise to include all of them just to cover the entire technology stack or component. The follow-up will become a drag on your project and make you miserable.

As long as you remember these six words: “There is a need, bring in”, you are OK. With the improvement of the project architecture and function, when there is a demand for a certain aspect, it is gradually considering whether to introduce some technical components.

2. Choose the technology you are most familiar with and most used

I think there is some truth to the saying that it is best not to use more than 30% of new technology in a new project. For the technology that you do not know or understand completely, you cannot predict and control any risks that may occur in the process of using it. Once problems occur, you will be embarrassed if you cannot solve them in a short time.

This does not mean that we refuse to use or contact new technologies. New technologies are worth pursuing, understanding and learning. To a large extent, some new technologies can bring us unprecedented benefits and solve problems that cannot be solved by other technological frameworks. The “new technology” mentioned here refers to the technology without sufficient investigation, technical verification, there are all kinds of doubts, but blindly borrowed, such risks can be imagined.

Make sure you choose the technology that is most used in the industry, that is widely accepted, and that you can handle it if things go wrong. At least in the small circles of the team.

3. Strong community-supported technology

The number of star on GitHub is an important indicator. At the same time, refer to the updating frequency of codes, documents and issues in recent years, and whether there are related technology sharing records in major technology blogs, which can explain whether the technology is active, popular and how many users.

Technology with strong community support, in the selection, if the use of questions, problems, bugs, etc., can have a place to mention, can be fixed, can be explored, after all, now the technical community is open enough.

Be careful to choose your own open source technical framework, components, etc. Few people can tell you exactly how many holes there are, and they may not exist any more someday.

4. Proceed from business and project scale

The starting point of any technology is to serve the final business, different business, different project scale, technical requirements are different indicators. In the initial stage of the business, the selection of the benchmark is relatively flexible, after all, the business is relatively simple, support business is not very large, as long as enough, high enough development efficiency. For projects in complex business reconstruction, selection needs to be cautious. It is often accompanied by the birth of some complex requirements and the uncertainty of the size. Therefore, we have to consider the selection technology may be accompanied by some minor repairs or spiraling reconstruction, so we need to select the technology that is easy to adapt, switch, replace and low coupling degree.

Because technology selection is relevant to business, we can observe some obvious phenomena: new technologies are often used by early-stage start-up teams or emerging businesses of large companies; Midsize and large companies tend to use technologies that have been stable for several years in their core businesses; Companies that use a technology for a long time tend to stick with it, even without updating it.

Learn to think from the business side. First of all, we need to fully understand the business, user needs, the current primary problems to be solved and the possible risks, and then break down the goals to carry out specific technology selection, model design and architecture design.

5. Verify the application before using it

The introduction of new technology and new ideas without verification must be cautious, and must be used on a large scale after all-round verification, and finally determine the type selection. Prudence does not mean conservatism. Technology is always moving forward. There is no problem in embracing change, but the introduction of immature technology seems to bring short-term benefits, but its risks or costs may be far greater than the benefits.

After verification, it is persuasive and more assured to use.

Three, technology selection

Each technical architecture has its advantages and disadvantages. It is reasonable to use different application architectures and technical frameworks for different business scenarios. It is not necessary to say that the latest architectures and technologies are the most suitable ones for you.

The selection of main technical frameworks often mentioned in microservice architecture is shown in the following table, based on which the comparison will be made later in this paper.

Fourth, service governance

1.Dubbo

Dubbo is a high-performance, lightweight, open source JAVA RPC framework and SOA service governance solution. In short, Dubbo is a service framework, and in plain English, a distributed framework for remote service invocation. It provides three core capabilities: interface-oriented remote method invocation, intelligent fault tolerance and load balancing, and automatic service registration and discovery, and is easily integrated seamlessly with the Spring framework.

The Dubbo logical architecture is shown below:

• Provider: Exposes the Provider of the service. You can start the service through a JAR or container.

• Consumer: Service Consumer that invokes the remote service.

• Registry: Service Registry and discovery center.

• Monitor: collects statistics on services and invocation times, and calls time monitoring center. (Dubbo can be seen on the console page, only a simple version is available)

• Container: The Container in which the service runs.

Dubbo features:

• Remote communication: provides abstract encapsulation of various long-connection-based NIO frameworks (non-blocking I/O communication, Mina/Netty/Grizzly), including multiple threading models, serialization (Hessian2/ProtoBuf), and “request-response” mode of information exchange.

• Cluster fault tolerance: Provides transparent remote procedure call (RPC) based on interface methods, including multi-protocol support (customized RPC protocol), soft load balancing (Random/RoundRobin), Failover/Failback, address routing, and dynamic configuration.

• Automatic discovery: Based on registry directory services, service consumers can dynamically find service providers, address transparency, and service providers can smoothly add or subtract machines.

Under the existing microservices architecture, Dubbo can only be described as a service governance framework, or an RPC framework, with interface granularity, and an interface class is a service. If you implement the microservices architecture directly with Dubbo, the following features are missing:

• Distributed configuration: This can be done using Spring Cloud Config, Apollo, etc.

• Link tracing: This can be done using Zipkin, CAT, etc.

• Batch tasks: This can be done using Dangdang’s open source Elastice-Job.

2.Spring Cloud

Spring Cloud is one of the most mainstream microservices architecture implementation preferred solutions. It is an open source framework based on Spring Boot. It is a whole family bucket and the overall technology stack of microservices.

Spring Boot is a quick configuration scaffolding for Spring that uses the idea of default being greater than configuration for the rapid development of individual microservices.

It provides simple implementations for service registration discovery, dynamic routing, load balancing, configuration management, message bus, fuses, distributed link tracking, big data operations, etc., so that we can use it more succintly.

As we have said before, microservices are service units that can be independently deployed, horizontally expanded and accessed, and Spring Cloud is the “big steward” of these microservices. After adopting the architecture of microservices, the number of projects will be very large, and the invocation link will be complex, so the management becomes a big problem. The Spring Cloud framework provides components to manage and govern microservices. Of course, this is the preferred framework.

The overall architecture of Spring Cloud is shown in the figure below, providing a one-stop microservice architecture solution.

Using Spring Cloud to build microservices architecture can save you the cost of integrating various technologies. Spring Cloud provides a one-stop solution for us to build microservices architecture. Just as Spring was born as a one-stop lightweight enterprise application development solution to solve many of the problems of EJB enterprise application development, as the number of products using Spring Cloud increases, Spring Cloud has become the dominant microservices architecture.

Here’s the full technology stack for Spring Cloud to see why it dominates the microservices architecture.

3. Compare and summarize

By comparing the above table, it is easy to see that Spring Cloud has many project modules that cover all aspects of the microservices system. Dubbo is an excellent service governance and service invocation framework, but it lacks many functional modules, such as gateways, link tracing, etc. In terms of project modules, Spring Cloud has a bigger advantage. Comparison does not mean to deny or praise anyone, but to show that advantages and disadvantages in different scenarios need to be viewed objectively.

If you focus only on this aspect of service governance, Dubbo is actually much better than Spring Cloud:

• Supports multiple serialization protocols, such as Hessian, HTTP, and WebService.

• The Dobbo Admin provides powerful background management functions, such as routing rules, dynamic configuration, access control, weight adjustment, and load balancing.

• In the domestic influence is relatively large, the Chinese community document is more comprehensive.

• Ali recently restarted maintenance as an Apache incubator project.

• Dubbo is more efficient using THE RPC protocol, more than doubling the efficiency of Spring Cloud under extreme stress testing.

Dubbo is recommended for high efficiency, which is much more efficient than RPC. If you choose microservice architecture to reconstruct the entire technical system, Spring Cloud is the right choice. It can be said that it is one of the best microservice frameworks at present, and it can be concluded that, Dubbo can be well integrated into Spring Cloud in the future.

5. API gateway

As a unique entry point for all services in microservices, API gateway prevents various mature technology framework components in the industry from having the following characteristics in particular when selecting technologies:

• High availability: The gateway is the only external gateway. It must be available 24/7 to provide stable and reliable services.

• High performance: All requests go through the gateway and it is under a lot of pressure, so it must be able to perform well to handle high concurrency requests.

• Security: The gateway must be able to prevent external malicious access and ensure the security of internal microservices.

• Scalability: The gateway is an excellent place to process non-service functions. It must provide services such as traffic control, protocol forwarding, and log monitoring, and provide good compatibility for the expansion of non-service functions in the future.

1.Zuul

As one of the core components in Spring Cloud, Zuul plays an important role as the API gateway. All requests can be sent through Zuul to back-end applications and services. Zuul provides features such as dynamic routing, monitoring, elastic load, and security. At its core, Zuul is a set of filters that act like those in the Servlet framework, or AOP.

Zuul uses various filters to implement the following functions:

• Dynamic routing: Requests are dynamically routed to the back-end cluster as needed.

• Authentication and security: Identify each resource that requires authentication and reject requests that do not meet the requirements, such as authentication.

• Statistical monitoring: Tracking and statistics data at service boundaries to provide an accurate view of statistical monitoring.

• Stress test: Gradually increase traffic to the cluster to understand its performance.

• Load offload: Capacity is allocated in advance for each type of request and is automatically discarded when the request exceeds capacity.

• Static resource processing: Returns some responses directly at the boundary.

These features make Zuul an API gateway of choice.

Zuul’s logical architecture is shown below:

Zuul’s filters do not communicate directly with each other. Instead, the data tradition is implemented through a class called RequestContext, which inherits ConcurrentHashMap and uses ThreadLocal variables to record the data that each Request needs to pass.

Zuul’s filters are implemented in Groovy. These filter files are stored in Zuul Server’s specific directories, which Zuul polls periodically, and the modified filters are dynamically loaded into Zuul Server for filtering requests.

Most of Zuul’s functionality is achieved through filters, with four standard filter types (Pre, Route, Post, and Error) defined for the different stages of application to the request.

(For a better understanding of Zuul, see the Zuul logical architecture diagram above and take a closer look at the Zuul source code.)

2.traefik

Before you get to know Traefik, take a look at its overall architecture, as shown below:

As you can see from the figure above, Traefik acts as an HTTP reverse proxy, making publishing services fun and easy. In microservices, it is essentially an HTTP reverse proxy and load balancing tool that is born in order to make the deployment of microservices more convenient. , it supports multiple backends (Docker, Swarm, Kubernetes, Marathon, Mesos, Consul, Etcd, Zookeeper, BoltDB, Rest API, File…) To automate and dynamically apply its configuration file Settings.

In addition to its many features, Traefik differentiates itself by automatically discovering the right configuration for your service. Instead of maintaining and synchronizing separate configuration files, everything happens automatically, in real time (no reboots, no broken connections). With Traefik, you can spend more time and energy developing and deploying rather than configuring and maintaining its working state.

Features:

• A high performance

• A single executable written in the Go language without installing additional dependencies

• Restful apis are supported

• Multiple backend support: Docker, Swarm, Kubernetes, Marathon, Mesos, Consul, Etcd

• Background monitoring, which can listen for background changes and automatically apply new configuration file Settings

• The configuration file is hot updated. (No need to restart)

• End the HTTP connection

• Back end circuit breaker

• Polling, rebalancer load balancing

• Rest Metrics

• Support for minimizing official Docker images

• Background SUPPORT SSL

• Front Desk SSL support (including SNI)

• Clean AngularJS front end page

• Support Websocket

• Support HTTP / 2

• Network error retry

• Support for Let’s Encrypt (automatic update of HTTPS certificates)

• High availability cluster mode

3.OpenResty

OpenResty is a high-performance Web platform based on Nginx and Lua that integrates a large number of fine Lua libraries, third-party modules, and most of the dependencies. It is used to easily build dynamic Web applications, Web services and dynamic gateways that can handle ultra-high concurrency and scalability.

OpenResty effectively turns Nginx into a powerful general-purpose Web application platform by bringing together a variety of well-designed Nginx modules, primarily developed by the OpenResty team. In this way, Web developers and system engineers can use the Lua scripting language to mobilize various C and Lua modules supported by Nginx, and quickly construct high-performance Web applications that are capable of concurrent single-machine connections over 10K or 1000K.

The goal of OpenResty is to have your Web services run directly inside Nginx services, taking full advantage of Nginx’s non-blocking I/O model, Provide consistent, high-performance responses not only to HTTP client requests, but also to remote backends such as MySQL, PostgreSQL, Memcached, and Redis.

4.Kong

Kong is a Lua application that runs in Nginx and can be implemented through the Lua-Nginx module. Instead of compiling Nginx with this module, Kong releases it with OpenResty, which already includes the Lua-nginx-Module, OpenResty is not an offshoot of Nginx, but a set of modules that extend functionality.

Is an Api Gateway that provides load balancing, logging, authentication, rate limiting, conversion, and more in the form of plug-ins. Easily scalable, modular, and run on any infrastructure.

At its core, it implements database abstraction, routing, and plug-in management, which can exist in a separate code base and be injected anywhere in the request lifecycle in a few lines of code. It’s easy to provide a variety of plugins for routing and services, and Kong supports all the basic features required by gateways:

• Cloud native: Platform-independent, Kong can run bare-metal to Kubernetes.

• Dynamic routing: Kong is behind OpenResty+Lua, so it inherits dynamic routing features from OpenResty.

• fusing

• Health check

• Log: Can record HTTP, TCP, UDP requests and responses through Kong.

• Authentication: Permission control, IP whitelist, also features of OpenResty.

• SSL: You can set up a specific SSL certificate for the underlying service or API.

• Monitoring: Kong provides real-time monitoring plugins.

• Authentication: support HMAC, JWT, Basic, OAuth2.0 and other common protocols.

• Current limiting

• REST API: The REST API is used for configuration management, which relieves complex configuration files.

• Availability: Naturally supports distribution.

• High performance: Backed by non-blocking communication nGINx, performance goes without saying.

• Plugins: Many plugins are available out of the box, and there is an easily extensible custom plugins interface that allows users to develop their own plugins using Lua.

The OpenResty behind Kong is mentioned repeatedly in these features. In fact, with Kong, Nginx can be completely abandoned because Kong’s functionality is the parent set of Nginx.

5. Compare and summarize

In conclusion, Zuul and Traefik are undoubtedly better in terms of open source community activity and learning cost. In terms of maturity, Kong and Traefik are better. From the point of view of performance, Kong is ahead of the others. From the point of view of the expansibility of architecture advantages, Kong is rich in plug-ins, while Zuul completely needs to develop various filters by itself. However, Zuul is also highly used due to its deep integration with Spring Cloud.

Service registration and discovery

Service registration and discovery is an old topic, which was born when applications started to run and access independently. In the current network architecture, each host has an independent IP address. Therefore, service discovery basically obtains the IP address deployed by the service in some way. DNS protocol is the earliest protocol to translate a network name into a network IP. In the initial architecture selection, DNS+LVS+Nginx can basically meet the discovery of all RESTful services. At this time, the IP list of services is usually configured in Nginx or LVS. With the advent of RPC services, services went up and down more frequently, and there was a search for a registry framework or component that could support dynamic going up and down and push IP list changes.

Nowadays, there are many frameworks and components for registering and discovering services (Zookeeper, Eureka, Consul, ETCD, etc.), and the choice is even more dazzling. In terms of service registration and discovery technology selection, I think we should follow certain principles and focus on points. Usually can proceed from the following aspects, focus on, choice.

• Data consistency

• Load balancing

• Health check

• Performance and capacity

• Ease of use

• Cluster scalability

• User scalability

7. Configuration center

In microservice architecture, the number of services and configuration information are increasing, such as various server parameter configurations, various database access parameter configurations, different configuration information in various environments, real-time effect of configuration information modification, etc. Traditional configuration files or storing configuration information in the database cannot meet the requirements of developers for configuration management. For example:

• Security: Configuration is kept in the code base along with the source code, which is prone to configuration leakage.

• Validity: The modification takes effect only after the service is restarted.

• Limitations: Dynamic adjustment, such as log switch and function switch, is not supported.

In microservices architecture, you must have encountered some of these problems before using a configuration center, so whether to introduce a configuration center depends on whether you have the following requirements:

• Centralized configuration unified management

• Configuration Takes Effect in Real Time

Generally perfect configuration center, will design from the following two aspects, in order to play the role of the configuration center.

1) The configuration takes effect in real time

In the traditional static configuration mode, you can only modify a configuration and then re-publish the application. To achieve dynamic configuration, you can choose to use the database and access the database through periodic polling to sense configuration changes. Low polling frequency leads to a long delay in sensing configuration changes, while high polling frequency leads to a short delay in sensing configuration changes. However, when comparing loss performance, a compromise between real-time performance and performance is required. The configuration center manages dynamic configuration based on real-time performance and consistency.

2) Configuration management process

A series of configuration management-related features, such as configuration permission control, gray distribution, version management, format verification, and security configuration, are not available in the configuration center. (This is also an advanced feature of configuration center.)

1.Spring Cloud Config

As a component of Spring Cloud, Spring Cloud Config has open functions and strong developability, and is often the cornerstone of self-development of various configuration centers.

From the source code of Spring Cloud Config (spring-cloud-config-server), it can be seen that the current support for local storage, Git repository storage, SVN repository storage, database storage, other storage methods can refer to the source code to achieve their own.

Take Git storage as an example. Spring Cloud Config contains config-server, Git and Spring Cloud Bus:

• Config-server Provides the client to obtain configurations.

• Git is used to store and modify configurations.

• Spring Cloud Bus notifies clients of configuration changes.

In local test mode, Spring Cloud Bus and config-server need to deploy one node, Git can use GitHub. In a production environment, Spring Cloud Config, config-Server requires at least two nodes. Spring Cloud Bus If RabbitMQ is used, the common cluster mode requires at least two nodes.

If you use GitHub for Git service, there is no need to consider the high availability problem. If you want to build your own private Git repository for security, the overall cost is relatively high. Web services can be deployed with multiple nodes to support high availability. Git has data consistency problems, so you can use the following methods to support high availability:

• Git+Keepalived cold standby mode, you can immediately switch to the standby Git when the primary Git is suspended.

• Git multi-node deployment, storage using network file system or DRBD to achieve data synchronization of multiple Git nodes.

2.Apollo

Apollo is a distributed configuration center developed by the Framework department of Ctrip. It can centrally manage configurations in different environments and clusters, and push configurations to applications in real time after modification. It has standardized permissions and process governance features, and is suitable for micro-service configuration management scenarios.

Apollo is divided into four modules: MySQL, Config Service, Admin Service and Portal.

• MySQL: Stores Apollo metadata and user configuration data.

• Config Service: reads and pushes configurations. Client requests are sent to the Config Service.

• Admin Service: modifies and publishes configurations. The Admin Service is operated by the Portal.

• Portal: provides a configuration and management page for users.

Local test Config Service, Admin Service, and Portal modules can be deployed together. MySQL installs and creates the required table structure separately. In the production environment, when Apollo is used, two Portal nodes can be deployed independently. If the stability requirements are not high, the Config Service and Admin Service can be deployed together, and databases support active/standby DISASTER recovery.

3.Nacos

Nacos is a dynamic service discovery, configuration management, and service management platform that makes it easier to build cloud-native applications. This is the official Nacos definition:

an easy-to-use dynamic service discovery, configuration and service management platform for building cloud native applications.

Core functions:

• Dynamically configuring services:

Dynamic configuration services enable you to manage the configuration of all environments in a centralized, external, and dynamic manner. Dynamic configuration eliminates the need to redeploy applications and services when configuration changes. Centralized configuration management makes it easier to implement stateless services and to extend services flexibly on demand.

• Service Discovery and Management:

Dynamic service discovery is key to a service-oriented approach to application architecture, such as microservices and cloud native. Nacos supports dnS-BASED and RPC-based (Dubbo, gRPC) service discovery modes. Nacos also provides real-time health checks to prevent requests from being sent to unhealthy hosts or service instances. With Nacos, you can more easily implement circuit breakers for your services.

• Dynamic DNS service:

By supporting weighted routing, the dynamic DNS service enables you to easily implement middle-layer load balancing, more flexible routing policies, traffic control, and simple DNS resolution services on the Intranet of simple data centers. Dynamic DNS services also make it easier to implement DNS protocol-based service discovery to eliminate the risk of coupling to vendor proprietary service discovery apis.

Nacos deployment requires Nacos Service and MySQL:

• Nacos Service: provides external services, including configuration management and Service discovery.

• MySQL: Provides persistent storage of Nacos data.

In single-machine mode, Nacos can be started by deploying a node using an embedded database. If you are familiar with MySQL and want to see the overall flow of data, you can install the MySQL data persistence service for Nacos. Production environments use Nacos, and Nacos services require at least three nodes deployed, plus MySQL active/standby.

4. Compare and summarize

Overall, THE deployment structure of Nacos is relatively simple and the operation and maintenance cost is low. Apollo has more components to deploy and higher operation and maintenance costs than Nacos. Spring Cloud Config is easy to customize for secondary development and has the highest cost of producing high availability.

Overall, Apollo and Nacos have a broader ecosystem than Spring Cloud Config and do a better job of configuration management processes. Apollo is more comprehensive in configuration management than Nacos, but it’s also a bit more cumbersome to use. Nacos is relatively simple to use and is better suited for large-scale scenarios with high performance requirements.

References:

1.dubbo.apache.org/zh-cn/

2. my.oschina.net/bigdataer/b…

3. github.com/netflix/zuu…

4.traefik.cn/

5.openresty.org/cn/

6. www.cnblogs.com/duanxz/p/97…

7. yq.aliyun.com/articles/69… content=g1000053369

8. blog.csdn.net/weixin_4433…

9. github.com/ctripcorp/a…

10.nacos.io/zh-cn/