今天看完了，ThoughtWorks 关于微服务架构治理的两个分享，记录下有意思的几个点。

  1. 架构腐化之谜
  2. 架构优化治理实践

腐化的现象

用户视角

  1. 软件无法使用
  2. 总是出现各种小问题
  3. 容易出现数据不一致

开发视角

  1. 新增功能困难
  2. 无法按时完成开发
  3. 修改容易引入bug且不容易快速发现

出现问题的原因

  1. 缺少对三方系统调用的监控和熔断机制， 三方接口的故障容易带来系统的不可用
  2. 核心流程 和 分支流程未分离解耦， 分支流程的奔溃导致系统不可用（比如同步调用的log服务崩溃， 导致核心流程不可用）
  3. 代码设计不合理， 未预留足够的扩展点， 导致新增功能困难
  4. 代码不clean， 阅读理解困难， 难以维护
  5. 代码测试覆盖不全面， 改动的bug很难快速发现

解决方案

  1. 三方接口集成规范
  2. 开源软件使用规范
  3. API设计规范
  4. 编码规范
  5. 无效日志
  6. 硬编码
  7. 一个函数多个职责
  8. 不好的命名和注释
  9. 方法不幂等

other

  1. 在早期无必要时， 服务不需要拆的那么细
  2. 微服务的腐化， 和代码的服务类似。 它的处理方案和处理代码腐化的方法类似，在合适的点划分服务，服务内聚， 服务功能单一，都是有效的方法。

SOLID

  1. SRP, single responsiblity principle（单一功能，单一职责）

  2. OCP, open close principle （公开的接口契约，不能修改close； 内部的实现可以修改， open）

  3. LSP, liskov substitution principle （子类是要实现父类的所有功能）

  4. ISP, interface segregation principle （接口要窄且深，不要宽且薄。 不要强迫caller依赖它不需要的方法，让caller自己组合它需要的接口）

  5. DIP, dependency inversion principle （依赖注入， caller依赖接口，不要依赖具体的实现。 接口 和 具体实现 的匹配， 由容器提供的策略来实现）