Original: https://mp.weixin.qq.com/s/UdLNAnLHo314ESKRUshVQQ
What is a microservice architecture?
Visually speaking , the microservice architecture is like building blocks, each microservice is a part, and these parts are used to assemble different shapes.
In layman's terms , the microservice architecture is to decompose a large system into multiple small systems with a single responsibility according to business functions, and use a simple method to make multiple small systems cooperate with each other and combine them into a large system.
From a disciplinary point of view , the microservice architecture is to aggregate functions that change for the same reason, separate functions that change for different reasons, and use a lightweight mechanism (usually HTTP RESTful API) to communicate;
Tracing the source, Martin Folwer's definition of microservice architecture is :
Microservice architecture is an architectural pattern that advocates dividing a single application into a set of small services, which coordinate and cooperate with each other to provide ultimate value to users. Each service runs in its independent process, and the services cooperate with each other using a lightweight communication mechanism (usually a RESTful API based on the HTTP protocol). Each service is built around a specific business and can be independently deployed to production environments, production-like environments, etc. In addition, for specific services, appropriate languages and tools should be selected to build them according to the business context. ( Excerpted from "Microservice Architecture and Practice" by Mr. Wang Lei )
For me personally , I prefer a continuous explanation, microservice architecture ≈ modular development + distributed computing
Summary: No matter what the definition of microservice architecture is, it is describing a core idea: splitting large systems into small systems and reducing major events into small ones to reduce the complexity of the system, thereby greatly reducing system construction, upgrades, and operation and maintenance. risks and costs.
The essential difference between "microservices" and "microservices architecture": Microservices " emphasizes the size of the service, and it focuses on a certain point. The " microservice architecture " is an architectural idea that requires a comprehensive consideration of the software system as a whole.
A false description: "" We can use microservices to solve this problem "; I also see more and more "so-and-so microservice frameworks", when in fact, these frameworks are not necessarily related to the microservice architecture Many links, they are just simple web frameworks.
It would be more appropriate to use the name "Microservice Architecture". It is an architectural style that organizes a series of collaborative services into a system to support a business .
Common Microservice Components and Concepts
1. Service registration
The service provider registers its own calling address with the service registry, so that the service caller can easily find itself
2. Service Discovery
The service caller finds the address of the service it needs to call from the service registry
3. Load balancing
Service providers generally provide services in the form of multiple instances, and the load balancing function enables service callers to connect to appropriate service nodes. Also, the work of node selection is transparent to the service caller.
4. Service Gateway
The service gateway is the only entry for service invocation. This component can implement functions such as user authentication, dynamic routing, grayscale publishing, A/B testing, and load current limiting.
5. Configuration Center
Register the localized configuration information (properties, xml, yaml, etc.) to the configuration center to achieve indistinguishable packages in development, testing, and production environments, and facilitate package migration
6. API management Write and update API documentation in a convenient form, and make it easy for callers to view and test
7. Integration Framework
Microservice components provide external services as packages with. The integration framework integrates all microservice components (especially management components) into a unified interface framework in the form of configuration, allowing users to use the system in a unified interface .
8. Distributed Transactions
For important business, it is necessary to ensure data consistency through distributed transaction technology (TCC, high-availability message service, best-effort notification)
9. Call chain
Record the microservices that are called when a business logic is completed, and display the serial or parallel calling relationship. When the system fails, it is easy to find the point of the error
Note: Follow Xiaocheng to learn microservices - expand the distributed call chain by yourself
10. After the support platform system is microserviced, the system becomes more fragmented, and the system deployment, operation and maintenance, monitoring, etc. are more complicated than the monolithic architecture. Therefore, most of the work needs to be automated .
Now, the drawbacks of these microservices architectures can be neutralized by tools like Docker. For example, continuous integration, blue-green releases, health checks, performance health, and more . Seriously, based on our two years of practical experience, it can be said that if there is no suitable supporting platform or tool, do not use the microservice architecture .
About microservice framework selection:
In general, if you want to quickly experience the benefits of the microservice architecture , you can get started quickly by using the three components of service registration (Eureka) , service discovery (Ribbon) , and service gateway (Zuul) provided by Spring Cloud. Other components need to be selectively used according to their own business
Additional: dubbo and spring cloud, microservice architecture comparison and alternatives see: Basic framework choice for microservice architecture: Spring Cloud or Dubbo?
Dubbo only implements service governance, and there are 17 sub-projects (may be added) under Spring Cloud that cover all aspects of the microservice architecture. Service governance is only one aspect of it. To a certain extent, Dubbo is just Spring Cloud Netflix a subset of . However, in the selection of the framework, the completeness of the scheme is precisely a content that needs to be paid attention to.
Dubbo Spring Cloud
| Service Registry | Zookeeper | Spring Cloud Netflix Eureka |
| Service call method | RPC | REST API |
| service gateway | without | Spring Cloud Netflix Zuul |
| breaker | imperfect | Spring Cloud Netflix Hystrix |
| Distributed configuration | without | Spring Cloud Config |
| service tracking | without | Spring Cloud Sleuth |
| message bus | without | Spring Cloud Bus |
| data flow | without | Spring Cloud Stream |
| batch tasks | without | Spring Cloud Task
|
Dubbo does not mean that the components summarized as "none" in the above table cannot be implemented, but the Dubbo framework itself does not provide it and needs to be integrated to achieve the corresponding functions, such as:
- 分布式配置：可以使用淘宝的diamond、百度的disconf来实现分布式配置管理。但是Spring Cloud中的Config组件除了提供配置管理之外，由于其存储可以使用git，因此它天然的实现了配置内容的版本管理，可以完美的与应用版本管理整合起来。
- 服务跟踪：可以使用京东开源的Hydra
- 批量任务：可以使用当当开源的Elastic-Job
- ……
虽然，Dubbo自身只是实现了服务治理的基础，其他为保证集群安全、可维护、可测试等特性方面都没有很好的实现，但是几乎大部分关键组件都能找到第三方开源来实现，这些组件主要来自于国内各家大型互联网企业的开源产品。
微服务架构优劣势分析
微服务架构和单体架构的对比
上手难度：API 接口调用 VS 数据库共享或本地程序调用,单体架构胜
待补
什么场景需要使用微服务架构
以上微服务架构和单体应用的对比，会让人产生一种错觉，微服务架构就是软件开发中的银弹。实际上，软件研发是一个系统工程，没有银弹，不能够一招鲜吃遍天。正如当年的 CMMI 和敏捷方法一样，敏捷虽好，但它不一定能适用于所有的场景，它对组织环境、团队氛围、沟通方式、技术能力这些都是有一些要求的，如果用不好，反而会带来一些负面影响。
作者认为有三种场景可以考虑使用微服务：
1.规模大（团队超过 10 人）
2.业务复杂度高（系统超过 5 个子模块）
3.需要长期演进（项目开发和维护周期超过半年）
借一张图来说明：
Tips: 横轴是复杂度，纵轴是生产效率。从生产效率的角度来讲，在两条曲线的交叉点之前，单体架构是占优势的，过了交叉点之后，单体架构的生产效率将大幅度下降。
对一种建议的保留态度：开始的时候先使用单体架构，当业务发展到一定程度的时候，再重构成微服务架构
在实践中，架构改造的难度还是很大的，会有一些问题，例如:
-
客户或业务部门是否给我们这样的时间窗口？
-
这段时间的研发经费是否有出处？
-
项目负责人或技术团队是否有主动的意愿进行架构升级？
-
项目负责人或技术团队是否愿意为架构升级带来的不稳定风险负责？
我们常常听到的一句话是：暂时先这样，等我们没这么忙的时候，再来优化一下。但是，绝大多数情况下，这一天从来没有出现过。
再想想年初，我们的私有云平台经过 2 年多的发展，已经包含了容器服务平台（PaaS）、API 网关、监控平台、定时任务平台、数据库管理、用户权限管理等等十多个基础模块，也包含了一些为上层应用服务提供的日志服务、缓存服务、消息服务等等。并且，部署到了二十多个客户的生产环境里。可悲的是，我们支撑了很多的业务系统的微服务化，但平台本身任然是一个单体系统。
我们也深深地感受到了平台往前发展的阻力：
-
很多时候，客户需要的不是一个大而全的平台，他们希望按他们的意愿采购需要的模块。
-
新人进入团队后，从熟悉到动手产出的时间偏长。
-
其它研发团队有一些比较好的组件能满足平台产品的需求，却不能直接拿来用。
-
两个不同的模块之间产生了不该出现的耦合关系，导致意想不到的 Bug。
所以，春节过后，大家开了一个会，决定将平台微服务化。而带来的代价就是要说服老板给我们两个月时间来重构。
幸运的是，我们很快得到了老板的支持，并且重构工作比较顺利；不幸的是，那二十多个客户的生产环境的升级非常麻烦，每升级一个客户都得花上一周左右的时间，至今也才升级了一小部分。
所以，理想的情况下，我建议在项目初期的时候就从上面提到的三点做好评估，到底采用哪种架构形式是符合项目具体情况的。
当然，如果真的有朋友想将历史悠久的单体架构升级到微服务架构，我建议先从边缘逻辑开始，逐步逐步地将业务逻辑从单体系统里剥离出来。我没有这方面的经验，但可以想象，这将是一个非常长期和痛苦的过程。