架构设计篇之微服务实战笔记（六）

第七章、构建可复用的微服务框架

构建一套微服务底座

跨团队实施统一实践的优势

在可复用框架中抽象公共关注点

7.1、微服务底座

严格规定团队能够使用的工具和编程语言，强制不同团队采用同一套标准方式创建服务，会损害团队的工作效率和创新能力（这里我不太认同，这种从长期来看收益大于短期，因为每个人技术水平层次不齐，统一技术框架方便提升工作效率，并深入做更多的事情，创新能力可以基于情况上变通，并非一开始就定义的则为正确的）

7.2、微服务底座的目的

• 让新加入的团队成员更容易上手

• 不管哪个团队使用的哪种技术栈，都能很好的理解代码结构和关注内容

• 随着团队共同的知识越来越丰富，生产环境的试验范围得到控制

• 有助于遵循最佳实践

比如哪些可以归到此类

• 日志

• 配置获取

• 度量指标收集

• 数据存储设置

• 健康检查

• 服务注册和发现

• 与所选择的传输协议相关的样例代码 AMQP，HTTP

本质是希望减少大量重复造轮子。

7.2.1、降低风险

持续性更新和维护

7.2.2、快速启动

对于重复的工作可以减少新人上手时间，快速启动项目。

7.3、设计服务底座

7.3.1、服务发现

可参考原来的笔记注册和服务发现开源项目

7.3.2、可观测性

• 度量指标

• 错误报告

• 日志

7.3.3、平衡和限流

可参考原来的笔记限流熔断开源项目

7.4、探索使用底座实现的特性

实现重要功能以后，探索收益大的内容进行逐步迭代

7.5、差异性是否是微服务的承诺

DRY 并不是强制的，服务底座不应该是包含在服务中并以中心化的形式进行更新的一系列共享库或者依赖。我们应该使用服务底座来创建和启动新的服务，而不需要为了特定的功能而更新所有运行中的服务。可以适当的重复。