架构师修炼系列【微服务设计与运行】

Davieyang.D.Y

已于 2024-07-10 12:58:04 修改

阅读量4.1w

点赞数 6

CC 4.0 BY-SA版权

分类专栏：互联网应用主流框架文章标签：微服务微服务架构

于 2021-10-05 19:22:14 首次发布

本文链接：https://blog.csdn.net/dawei_yang000000/article/details/120607679

互联网应用主流框架专栏收录该内容

63 篇文章

订阅专栏

微服务架构强调每个服务独立部署，高内聚低耦合，通过点对点或异步消息协议协作。它降低了复杂系统的相互影响，提高了可维护性和扩展性。微服务的特点包括独立部署、可替代性、数据独立、服务编排和透明性。与SOA不同，微服务更注重服务的自治和业务内聚。开发中应遵循自治性、可恢复性、透明性、自动化和一致性的原则，确保服务稳定、可扩展和易于管理。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

微服务应用

通常在单体系统中，开发者会在类、模块、类库的层面来设计功能属性，而在微服务应用中，开发者的目标则变成了可独立部署的功能单元，而每个功能单元以一些复杂的方式进行交互，功能单元之间的相互协作则是通过一系列消息协议来完成，而这些协议可能是点对点的也可能是异步的，每个功能单元共同合作起来形成了一个更加复杂的系统
微服务发展至今已并非新鲜事物，而其定义也非常容易理解，但它确实能够显著的降低复杂系统开发过程中的相互牵扯和冲突，且同时具备了软件工程实践倡导的【高内聚】【低耦合】，很显然具备这样特点的系统更容易维护、易扩展，通过这些手段完成为客户持续交付价值的最终目的，这里的重点在于持续交付，而如果更高维度考虑，将其与商业行为结合，这个最终目的应该是为客户快速的持续的交付价值，于是这里的重点便多了一个维度即快速的持续的

微服务特点

概念是非常容易懂的，稍微有几年开发经验的开发者一看便知道其中的意义，但到了实操层面具体该怎么做技术设计又无从下手，如果说微服务的概念告诉了我们它解决了什么问题，那么微服务的几个特点【我更愿称之为原则】告诉了我们应该如何做技术设计

高内聚低耦合

内聚度时用来衡量某个模块中的各个元素属于一个整体的紧密程度的指标，耦合度则是衡量一个元素对另一个元素的内部运转逻辑了解程度的指标，而在讨论内聚和耦合的时候，单一职责原则便是一个很少的提升内聚的手段即：将那些因相同原因而修改的内容聚合到一起，将那些因不同原因而修改的内容进行拆分
单个微服务应该是高内聚的，它应该只负责应用的一个功能，同样每个服务对其他服务的内部运转逻辑知道的越少就越容易修改，而不需要让其他服务跟着一起修改

场景实例

考虑一下出售股票的场景，大致需要如下4步处理

用户创建一个订单，用来出售其账户里某只股票的股份
账户中的这部分持仓就会被预留下来，确保相同的股份不可以被多次出售
提交订单到市场上需要缴纳印花税
系统需要将这个订单发送给对应的股票交易市场

如图所示微服务设计，它是整个交易系统的一部分

在这里插入图片描述

从图中可以看到，微服务的三大关键特点：

每个微服务只负责一个功能，这个功能可能是业务相关的功能，也可能是共用的技术功能，比如与第三方的集成
每个微服务都拥有自己的数据存储，这是降低耦合非常关键的设计，各服务之间的数据访问，仅可以通过服务提供的接口来访问它们自己所不拥有的数据
微服务自己负责编排和协作(控制消息和操作的执行顺序来完成某些有用的功能)，既不是由连接微服务的消息机制来完成的，也不是通过另外的软件功能来完成的

除了以上的三大特点外，还有两个基本特性：

每个微服务都可以独立部署，如果做不到，那么到了部署阶段微服务应用还是一个庞大的单体应用，而团队不能仅仅考虑到coding的部分，还需要考虑部署、监控、诊断等一些列环节，如此微服务才能发挥其作用
每个微服务都是可代替的，每个微服务只具备一项功能，所以这很自然地限制了服务的大小，同时每个服务的职责或角色更加易于理解