Distributed service development is complicated by interaction, coordination, governance, etc. between services. The complexity of the service is transferred from the application itself to the network interaction layer.
1. About the 12-factor problem
When developing distributed services, we usually consider 12-factor issues, such as configuration centers, stateless, logs, etc.
One code base: a centralized code management platform that supports multi-person collaborative development.
A dependency library: service dependency release, storage, isolation and other management.
A configuration center: a centralized configuration management center, service, and coordination of multi-service applications.
Pluggable support services: such as databases, message middleware, third-party services, etc.
Build, release, run process management: service release management.
Each service instance is a stateless worker process.
Services provide external services by binding specific ports.
Service scaling is achieved by increasing or decreasing the type and quantity of service instances.
Fast startup and graceful shutdown enhance service robustness.
Keep development, testing, and production environments as consistent as possible.
Logs are processed in the form of event streams, separating impacts.
Script or command-line service management tool support.
2. Overview
Borrow a picture:
3. Service Discovery
When services are provided by multiple service instances, the client needs to know which services can be called, where the services are located, and how to call them.
Distributed Coordination Service: Service Registration and Discovery. Such as Eureka (AP), Consul (CP), Zookeeper (CP), Nacos (CP + AP) and Etcd (CP), etc.
Example Nacos architecture diagram:
4. API Gateway
There is a many-to-one relationship between the client and the server. For supporting functional requirements involving unified authority management, routing load, logging, and monitoring, gateway service processing is relatively more suitable. Such as Spring Cloud Gateway , nginx , OpenResty , zuul , APISIX , etc.
Example Spring Gate Way workflow:
5. Configuration Center
Independent service configurations can be integrated with services. For the distributed multi-service model, flexible and centralized configuration management is very necessary.
The configuration center generally needs to provide configuration addition, deletion, update management, environment management, grayscale management, version control, etc. Such as Apollo , Nacos , Spring Cloud Config, etc.
Apollo vs Spring Cloud Config：
| function points | Apollo | Spring Cloud Config | Remark |
|---|---|---|---|
| configuration interface | One interface to manage different environments and different cluster configurations | None, need to operate through git | |
| Configuration effective time | real time | Restart to take effect, or manual refresh to take effect | Spring Cloud Config needs to pass Git webhook, Add an additional message queue to support real-time effect |
| version management | Release history and rollback buttons are provided directly on the interface | None, need to operate through git | |
| Gray release | support | not support | |
| Authorization, review, audit | It is directly supported on the interface, and supports modification and release permission separation | It needs to be set through the git warehouse, and does not support modification and release permission separation | |
| Instance configuration monitoring | You can easily see which configurations are currently being used by which clients | not support | |
| configuration fetch performance | Fast, through database access, and cache support | Slower, need to clone repository from git, then read from file system | |
| client support | Native support for all Java and .Net applications, Provide API to support other language applications, It also supports Spring annotation to get configuration |
Support Spring application, provide annotation to get configuration | Apollo has a wider scope of application |
Digression:
Related Content Expansion: (Technical Frontier)
In the past 10 years, when even traditional enterprises began to digitize on a large scale, we found that in the process of developing internal tools, a large number of pages, scenes, components, etc. were constantly repeated. This repetitive work of reinventing the wheel wasted a lot of time for engineers.
In response to such problems, low-code visualizes certain recurring scenarios and processes into individual components, APIs, and database interfaces, avoiding repeated wheel creation. Greatly improved programmer productivity. Experience official website: https://www.jnpfsoft.com/?csdn
Recommend a software JNPF rapid development platform that programmers should know, adopts the industry-leading SpringBoot micro-service architecture, supports SpringCloud mode, improves the foundation of platform expansion, and meets the needs of rapid system development, flexible expansion, seamless integration and high Comprehensive capabilities such as performance applications; adopting the front-end and back-end separation mode, front-end and back-end developers can work together to be responsible for different sections, saving trouble and convenience.
If you haven't understood the low-code technology, you can experience and learn it quickly!
6. Service Governance
Distributed services involve coordination among multiple services to jointly provide external services. Relatively speaking, there will be more uncontrollable factors affecting its availability, such as call timeout between services, traffic overload, etc., so service governance is also a required course.
Circuit breaker, flow control support: Spring Cloud Circuit Breaker , Resilience4J , Sentinel , Hystrix .
Sentinel example :
7. Link Tracking
Distributed services make problem tracking very difficult, and it is necessary to comprehensively locate the problem by integrating the performance of different service nodes on the request path. Therefore, first of all, there needs to be a chain, a complete tracking link from the request call entry to the bottom layer of the service and then back.
Support components such as: Spring Cloud Sleuth, Zipkin, SkyWalking.
Example SkyWalking architecture diagram:
8. Log
Summarize and display all service logs sequentially. Including log collection, transmission, warehouse storage and display, etc.
Typical example is ELK , logstash is responsible for collecting and transmitting log data, ElasticSearch is responsible for storage, and Kibana is responsible for query and display.
There are many optional collectors for data collection: such as filebeat (lighter), logstash, Fluentd, etc.
9. Monitoring
（Prometheus | Zabbix）+ Grafana ）
1、Promethueus
Open source system monitoring and alarm system. Responsible for collecting, storing and displaying time series monitoring data. The overall structure diagram is as follows:
2、Zabbix
Open source distributed monitoring solution.
3、Grafana
Provide query, multi-dimensional visual display, alarm and other functions.
