微服务架构系列主题：微服务实现的反模式及正确做法

Posted 2021-09-09 LarryHai6

前言

程序员在程序开发的时候，经常会使用到设计模式，或在面试过程中也经常被提问到设计模式。

所以大家对设计模式比较熟悉了，但大家知道“反模式”吗，什么叫“反模式”？怎样才能避免“反模式”的发生。所以今天的文章，我会从三部分的内容进行讲解。

1. 重新理解一下“模式”和“反模式”的定义

2. 基于微服务实现的“反模式”

3. 微服务的正确做法，来避免“反模式”的发生

1. 重新理解一下“模式”和“反模式”的定义

我们看一下“模式”和“反模式”在维基百科的定义。

根据维基百科的定义，设计模式是一套被反复使用，多数人知晓的，经过分类编目的代码设计经验的总结，是软件设计的某些特定场合的某些问题的解决思路。是前人经过大量的实践，总结出来的无论从效率、扩展性、复用性、可靠性等方面都显现出优势的解决思路。

反模式（anti-pattern）指的则是在实践中明显出现，但低效或有待优化的设计模式，是用来解决问题的带有共同性的不良方法。

2. 基于微服务实现的“反模式”

以下是我从架构，交付和运维，产品，组织，技术这几个维度总结出来的，微服务实现的“反模式”，供大家借鉴参考。

分类	反模式	影响
架构	使用微服务并没有判断其复杂性	在没有投资回报的情况下承担复杂性成本
	试图使用工具来解决问题	看不到预期的好处，架构的保质期缩短
	没有针对于可扩展性进行进行架构设计	在没有充分利用的情况下导致微服务体系结构的复杂性
	试图在跨服务中保持事务的意图	最终，不工作。但很多的时间被浪费在流程当中，因此成功被延期了。
	没有针对于可扩展性进行架构设计	架构变得脆弱 -  局部的失败级联到整体
	没有封装数据	服务变得耦合
	没有针对内部服务通信进行设计	能导致服务耦合，导致不必要的通信失败。
	服务过大	架构没有产生预期的结果
	服务过小	由于失去高能聚，变得难于维护。
交付和运维	没有自动化的软件交互和运维	微服务变得难于维护，人为干预造成很多问题。
	没有自动化的资源分配	手动很难做，能导致大量的过度资源很配
	没有构建质量	浪费的，使自动化软件交付变得很难。
	没有调整测试方法	导致质量变差，可用性变低
产品	没有调整用户界面随着一致性模型改变	能导致误导产品界面和数据质量问题发生
组织	没有针对去中心化执行进行操作模式的变化	阻止服务的独立运维
	基于软件组件或技术进行构建	服务变得耦合
	保持开发团队和业务分离	能导致低质量和时间缺失
	没有把人作为成功的因素	很差的质量，时间浪费，没有看到预期结果。
技术	没有治理组织的技术演变	能导致长期的技术债
	没有安全管理	假如没有被积极的管理，微服务可以打开很多的攻击载体。

3. 微服务的正确做法，来避免“反模式”的发生

所以针对于以上的微服务实现的“反模式”，以下是微服务应该被实现具备的特性，来避免“反模式”的发生。

微服务应该被实现具备以下特性：

• 服务按照业务能力进行构建

• 服 务是小的，并聚焦的

• 服务内部逻辑被封装，对于其它服务不可见

• 架构需具备可扩展性和弹性

• 服务集成通过正式的 API, 使 用合适的契约，版本，序列化，传输等

• 架构为云做好了准备，即使在短期内没有上云的计划

• 内部服务的通讯模式已确定

• 设计支持通信架构（网关，服务网格等）

• 操作模型被确立：

• 促进去中心化执行

• 促进技术的演进

• 支持跨职能团队基于业务能力进行组织，与业务紧密相关

• 跨职能团队围绕业务能力被组织，被服务支持

• 服务之间彼此独立的开发，交付和运维。

• 优秀的技术实践被使用，例如： 单 元测试， TDD ， BDD 等

• 软件交付，测试，运维是自动化的

• 资源分配 是自动化的

• 安 全被积极的管理，并集成到软件的生命周期

所以在使用微服务架构的过程中，需要避免微服务实现的“反模式”发生，这样你才能得到微服务架构带来的好处。