​
今天将从存储的上一层「服务维度」学习架构师的第二项常用能力 —— 微服务设计与治理。

创新互联建站一直在为企业提供服务，多年的磨炼，使我们在创意设计，成都营销网站建设到技术研发拥有了开发经验。我们擅长倾听企业需求，挖掘用户对产品需求服务价值，为企业制作有用的创意设计体验。核心团队拥有超过十载以上行业经验，涵盖创意，策化，开发等专业领域，公司涉及领域有基础互联网服务IDC机房托管、app软件定制开发、手机移动建站、网页设计、网络整合营销。

这是我们对微服务进行架构设计过程中非常关注的两个问题。

本文对微服务的生命周期定义了七个阶段，如下图所示。

围绕这七个阶段总结了 16 条常用原则。

1、微服务规划
原则 1：按照业务能力（business capabilities）来规划或拆微服务。
康威定律：Conway’s law: Organizations which design systems […] are constrained to produce designs which are copies of the communication structures of these organizations.
（设计系统的组织，其产生的设计和架构等价于组织间的沟通结构。)

组织的沟通和系统的设计之间紧密相连，特别是复杂系统，解决好人与人的沟通才能有一个更好的系统设计。

《人月神话》中总结出了随着人员的增加沟通成本呈指数增长的规律：沟通成本 = n (n-1)/2。举例说明：

系统越复杂，人手越多，沟通成本也呈指数增长。因此，分而治之便是大多数公司选择的解决方案。分不同的层级，分不同的小团队，让团队内部完成自治理。

领域驱动设计是微服务领域的热门话题，本文不展开说明，仅说明几点重要事项：

2、微服务设计

所谓单一职责原则，就是对一个服务而言，它的功能要单一，只做与它相关的事情。在微服务的设计过程中要按职责进行设计，彼此保持正交，互不干涉。

什么样的单一领域对象的单一职责微服务才是有价值的？就是不断有业务变化，能够维持业务持久性，有业务生命力的领域对象。举例来说：

那么就很有价值独立为一个微服务，实现独立演进、个性化的弹性伸缩。

所以，我们在进行微服务设计时，要能够分析、预测出需求变化的点在哪里？高并发的点在哪些？数据增长的位置在哪里？与 DDD 分析相结合，找出最有价值的那个单一职责，进行合理、适度的领域、子领域、有界上下文分解，才能更好的应对复杂的业务、不断变化的业务。

过度追求「单一职责」，或者拆分微服务过细，往往会带来不良后果。微服务的设计并不是越细越好，过度拆分会导致调用性能变差、数据一致性难以保障、系统可用性降低等问题。

因此，「高内聚」原则要求：

原则 5：微服务的设计应该遵循「低耦合」原则

3、微服务实现
原则 6：服务无状态。
什么是「状态」？如果一个数据需要被多个服务共享，才能完成一笔交易，那么这个数据被称为状态。

依赖这个「状态」数据的服务被称为有状态服务，反之称为无状态服务。

「无状态」原则并不是说在微服务架构里就不允许存在状态，而是要把有状态的业务服务改变为无状态的计算类服务，那么状态数据也就相应的迁移到对应的 “有状态数据服务” 中。

场景说明：例如我们以前在本地内存中建立的数据缓存、Session 缓存，到现在的微服务架构中就应该把这些数据迁移到分布式缓存中存储，让业务服务变成一个无状态的计算节点。迁移后，就可以做到按需动态伸缩，微服务应用在运行时动态增删节点，就不再需要考虑缓存数据如何同步的问题。

只有服务无状态，才能实现快速弹性扩缩容，应对流量峰谷。

原则 7：服务高可用。
接入高可用中间件（如 sentinal)，实现限流、熔断、降级，增强可用性

原则 8：服务可观测。
除了默认系统监控外，微服务需要梳理并定义必要的「业务监控指标」。

原则 9：服务配置可管理。
微服务相关配置需要统一接入配置中心进行管理、控制。

4、微服务调用
原则 10：避免「分布式大单体」
只做单向调用，避免循环调用。

多个服务循环依赖调用形成集中式 “分布式大单体”，违背微服务的原则。

原则 11：异步解耦。
按需接入消息队列，实现「依赖解耦」、「流量削峰」

原则 12：引入 BFF 层，降低客户端与后端微服务之间的耦合
尽量设计 BFF 层，把前端的特殊需求交给 BFF 层，使后端服务逻辑具有高内聚、高复用性的精简核心逻辑。

5、微服务发布
原则 13：服务发布遵循安全发布三板斧
保证「可灰度」、「可监控」、「可回滚」。

6、微服务治理
原则 14：正视「架构腐化」，遵循「持续演进」原则
「架构腐化」的常见场景：

「水平扩容」比较容易理解，直白点说就是加机器。根据 AKF 模型，除了加机器外，我们还可以考虑「功能拆分」或者 「数据分区」。

「功能拆分」相对复杂，一般包括几种模式：

「数据分区」往往指的是数据库层面。需要引入数据库中间件，像 sharding-jdbc、mycat 等，在数据层面需要配置相应的分片逻辑。正确的拆分对提高系统的容量有很大的帮助，失败的拆分可能会造成热点集中，得不偿失。常用的分区逻辑包括 按照时间分区、按照用户 id 取模分区等。

7、微服务下线
原则 16：对于「废弃服务」，需要做好「下线」工作，包括服务下线、存储释放等。
清理无效代码、环境，减少维护成本。同时释放资源，节约成本。

8、总结
架构师在进行微服务设计和微服务治理时，可以围绕微服务生命周期的七个阶段展开。

本文总结了 16 条常用原则，希望能提供一些思路和启发。

​

你是否还在寻找稳定的海外服务器提供商？创新互联www.cdcxhl.cn海外机房具备T级流量清洗系统配攻击溯源，准确流量调度确保服务器高可用性，企业级服务器适合批量采购，新人活动首月15元起，快前往官网查看详情吧

当前文章：架构师进阶，微服务设计与治理的16条常用原则-创新互联
文章来源：http://ybzwz.com/article/ggeed.html