【金秋打卡】第10天 构建微服务设计架构知识体系--如何拆分单体架构至微服务

课程名称：海量数据高并发场景，构建Go+ES8企业级搜索微服务

课程章节：5-4

课程讲师：少林码僧

课程内容：

• 什么是微服务

  • 在服务化的基础上进一步演化，服务原子化，数据独立

  • 围绕业务能力通过多个小型服务组合来构建单个应用的架构风格

  • 轻量级的通信，自动化的部署
    

• 什么时候开始微服务化

  • 产品初期可以先用单体架构

  • 微服务化是业务在单体架构已经非常庞大，不得不拆分的时候才被迫去做的

  • 确保基础设施和公共基础服务已经准备好了。比如中间件集群，自动化部署，链路追踪，弹性伸缩等
    

• 拆分粒度

  • 团队规模，决策占比50%

  • 交付速度要求，决策占比30%

  • 其他占20%
    

• 拆分粒度衡量

  • 内部复杂度。又称之为单体复杂度，指单个对象内部的复杂度。

  • 可以用参与开发人数来衡量，3个火枪手原则：三个人的原因是系统复杂度刚好达到每个人都能全面理解整个系统的程度。3个人可以形成一个稳定的备份。三个人既能形成有效的讨论，又能够快素达成一致

  • 群体复杂度，指拆分后多个对象之间的关系复杂度

  • 交付周期以天为单位

  • 大多数交付功能是否可以在一个服务内完成，也是衡量拆分粒度的标准，如果拆的太开，导致一个需求需要好几个服务，那么长此以往，就要考虑功能转移和合并的问题
    

• 内外平衡原则 

  • 多数服务不仅仅要关心自己本身的实现，还要考虑外部调用的难易程度，如果一个服务被经常调用，而又经常更新，依赖此服务的其他服务就要不停的修改以适应新版本

• 先粗后细原则

  • 要先进行大体上的构建，不要一开始就追求细节，等到整体能运作的时候，再逐一补充TODO
    

• 2年原则和演进原则

  • 最多预测2年后的情况，不要再预测更多了，实际上能预测半年后的计划已经能满足基本开发。。

  • 对还没有用到的组件不要提前接入
    

• 微服务的拆分后会带来哪些问题

  • 一致性的实现成本变高

  • 整体延时变高

  • 资源成本变高

  • 关联查询复杂度变高

  • 涉及更多的远程调用

  • 需要服务治理

  • 对开发人员的要求变高

  • 对工具的依赖变高

  • 运维复杂度变高
    

课程收获

微服务拆分过程中会遇到很多问题，直观的表现在成本的提升，微服务成本高，对大型项目来说收益也高，微服务并非百利而无一害，要在成本和收益之间找平衡点