微服务之旅
记录我所经历的微服务架构变更过程。
单体应用
初期最常见的一种架构模式，采用单体架构，服务端和页面在一个war包项目中。
优点
上线最快，用于验证业务模式
缺陷
- 页面通过jsp、velocity等服务端渲染，开发成本大，效率低。 e.g. java开发将html修改为jsp时产生布局样式偏差错误
- 前后台同时操作同一个DB表
- DW和BI订阅业务表，业务端暴露了存储结构并耦合
- 发生任何变动，需要整体部署
初探微服务
在业务深耕的过程中，单体应用已经难以应付业务复杂度和数据量。多需求同时迭代，在分支合并时总是带来意想不到的问题。而高耦合的应用导致，前端页面的变更，也需要所有服务发布。架构师为了救我们于水火之中，给我们带来了微服务。概括来讲，就是拆！
- 服务端拆分，业务按db结构拆分为不同的微服务，上层产品服务调用微服务，负责聚合编排。
- 前后端分离，nodejs替换服务端渲染，负责页面展示、路由及登陆鉴权。
优点
- 前后端分离，职责清晰，开发效率提升，服务不需要频繁发布
- 通过微服务调用，隐藏内部表结构，拆库拆表
- 减小修改范围，快速部署
- 基于不同微服务的性能表现，针对性横向扩容
缺陷
- 基于表结构建模，导致众多贫血、CRUD的微服务
- 产品服务编排底层微服务，多次通信导致耦合
- 被BI、DW同步的表，无法拆分
- 调用链路增加导致测试以及问题排查成本增加
微服务治理
经过一段时间的积累沉淀，开发人员对微服务、对业务都有了更深层次的理解。为了更加明确业务领域，提升系统的扩展性、应对日益增多的流量以及服务于能力输出的开放平台，有必要对现有微服务进行一次治理。
- 通过框架，跟踪记录每次调用链路
- 提升CI/CD，节约部署成本
- 服务应该基于业务上线文，明确服务需要处理的业务及系统中位置，其次再考虑需要保存什么样的数据。基于业务领域，承担并暴露更具业务含义的接口
- 通过协同，替换编排，抽离配置业务流程。
- 通过消息中间件，解耦DB和其他部门之间的数据同步
优点
- 领域职责明确
- 扩展性强
缺陷
- 开发成本增加
总结
- 技术选型本质上是取舍判断，比较得到的优点以及不得不面临的缺陷
- 不存在最牛的架构，只有当前阶段最适合的架构。所以在这里，我列出每次架构变更时的优缺点，希望可以作为参考
- 技术架构和人员组织会相互影响
- 高内聚、低耦合