微服务之旅

记录我所经历的微服务架构变更过程。

单体应用

初期最常见的一种架构模式,采用单体架构,服务端和页面在一个war包项目中。

优点

上线最快,用于验证业务模式

缺陷

  1. 页面通过jsp、velocity等服务端渲染,开发成本大,效率低。 e.g. java开发将html修改为jsp时产生布局样式偏差错误
  2. 前后台同时操作同一个DB表
  3. DW和BI订阅业务表,业务端暴露了存储结构并耦合
  4. 发生任何变动,需要整体部署

初探微服务

在业务深耕的过程中,单体应用已经难以应付业务复杂度和数据量。多需求同时迭代,在分支合并时总是带来意想不到的问题。而高耦合的应用导致,前端页面的变更,也需要所有服务发布。架构师为了救我们于水火之中,给我们带来了微服务。概括来讲,就是

  1. 服务端拆分,业务按db结构拆分为不同的微服务,上层产品服务调用微服务,负责聚合编排。
  2. 前后端分离,nodejs替换服务端渲染,负责页面展示、路由及登陆鉴权。

优点

  1. 前后端分离,职责清晰,开发效率提升,服务不需要频繁发布
  2. 通过微服务调用,隐藏内部表结构,拆库拆表
  3. 减小修改范围,快速部署
  4. 基于不同微服务的性能表现,针对性横向扩容

缺陷

  1. 基于表结构建模,导致众多贫血、CRUD的微服务
  2. 产品服务编排底层微服务,多次通信导致耦合
  3. 被BI、DW同步的表,无法拆分
  4. 调用链路增加导致测试以及问题排查成本增加

微服务治理

经过一段时间的积累沉淀,开发人员对微服务、对业务都有了更深层次的理解。为了更加明确业务领域,提升系统的扩展性、应对日益增多的流量以及服务于能力输出的开放平台,有必要对现有微服务进行一次治理。

  1. 通过框架,跟踪记录每次调用链路
  2. 提升CI/CD,节约部署成本
  3. 服务应该基于业务上线文,明确服务需要处理的业务及系统中位置,其次再考虑需要保存什么样的数据。基于业务领域,承担并暴露更具业务含义的接口
  4. 通过协同,替换编排,抽离配置业务流程。
  5. 通过消息中间件,解耦DB和其他部门之间的数据同步

优点

  1. 领域职责明确
  2. 扩展性强

缺陷

  1. 开发成本增加

总结

  1. 技术选型本质上是取舍判断,比较得到的优点以及不得不面临的缺陷
  2. 不存在最牛的架构,只有当前阶段最适合的架构。所以在这里,我列出每次架构变更时的优缺点,希望可以作为参考
  3. 技术架构和人员组织会相互影响
  4. 高内聚、低耦合

Welcome to my other publishing channels