Curias Blog

欲以犀利知性换啤酒,一杯又一杯。

  1. 1. 为什么选择微服务
  2. 2. 用代码堆彻的沙堡之城
  3. 3. 痛点
    1. 3.1. 组织
    2. 3.2. 隔离
    3. 3.3. 协作
  4. 4. 解决
    1. 4.1. 分离数据库
    2. 4.2. 搭建dev开发环境
  5. 5. 小结

为什么选择微服务

由于多人共同维护一个项目实在是太麻烦,团队打算引用微服务技术栈,将代码按业务拆分为多项不同微服务单独维护,促使这样做的原因有以下几点:

  1. 提高开发速度:单人或几个人维护一个微服务可以有效避免开发中的代码冲突问题,另外小团队的代码更容易理解,修改和维护。
  2. 技术管理较为自由:你可以自由选择最新的技术和轮子。

用代码堆彻的沙堡之城

在微服务架构完后,业务开发人员开始填充代码,这个阶段下,新需求能在微服务上写的都会在微服务上完成,老的项目中的功能点也逐步的迁移到新项目中,由于存在多个服务频繁调用的基础服务,又新建了基础服务中台和数据中台,由于各个服务直接关联不大,这一阶段还算顺利且愉快。

痛点

组织

自由且缺乏管理会产生乱象,在人为因素的驱动下做出技术决策时,我们很快就会遇到了问题。新团队的组织和流程很难与现有的团队并行不悖。由于特性是独立开发的,很快就出现了知识分化。微服务内部的东西没法共享,而跨栈代码审查的缺失让我们觉得失去了 ownership。

隔离

在上面的架构中,微服务 Customer Success 并非完全隔离。从单体到微服务存在后端到后端的通信,反之亦然。这并不完全是坏事),但这还是会降低性能,并在两个服务之间创建依赖关系。从长远来看,这还意味着更复杂的机制,如 circuit breakers 和优雅的服务降级(为保证正常运行时间和可用性)。

由于后端数据库是共享的。在数据库内部修改共享表的字段需要对微服务和单体进行同步修改。这也是由糟糕的领域隔离所导致的。

协作

不得不承认,当每个服务发展到一定程度,其与其他服务的耦合度是非常高的,而且每个服务可以独立部署导致需要同步部署依赖服务,我们内部每个微服务是通过版本号去迭代的,这就需要服务1如果有重大升级,那么其依赖服务1的所有服务都需要升级版本并同步部署一次。

解决

分离数据库

在项目发展到一定程度后,分离数据库就成了一种必然选择。

搭建dev开发环境

在公司内部搭建本地的dev开发环境,环境由团队共同维护,可以有效解决不同服务间的调用及调试问题。

小结

本文不是要批评微服务,目前微服务架构在团队中还是利大于弊的存在,但是我们也要正视他存在的问题,并逐步的去解决他。

本文最后更新于 天前,文中所描述的信息可能已发生改变