微服务架构服务建模方法+服务拆分和集成5:拆分后应对新业务增长处理+持续拆分+如何保证拆对了

目录

一、拆分后业务变了增加了怎么办?

二、如何安全地持续地拆?

三、如何保证拆对了?

参考书籍、文献和资料:


一、拆分后业务变了增加了怎么办?

客户的业务是在变化的,我们对业务的认知也是逐渐的过程,所以Martin Fowler在他的文章中提出,系统的初期建议以单体结构开始,随业务发展决定其是否被拆分或合并。那么这也意味着这样构建的服务在它的生命周期中必然会持续被拆分或合并。那么为了实现这样一个目标,使系统拥有快速的响应力,也要求这样的拆分必然是高效的低成本的。

因此,服务的设计需要满足如下的原则:

  • 服务要有明确的业务边界,以单体开始并不意味着没有边界。 服务要有边界,即使以单体开始也要定义单体时期的边界。我们系统中有一个名为“Monkey”的服务,是在中国虎年启动的,由此它并不是一个业务概念。当这个服务的名字为MonkeyAPI时,可以想象5年来它变成了什么?几乎所有和这个产品相关的功能都放入了这个服务中。脱离平台来看这一个产品的系统,其实它只是做了前后端分离而已。这个例子告诉我们,没有边界就会导致大杂烩,之后对其进行整理和重造的代价很大,可能需要花费“几代人”的努力。
  • 服务要有明确清晰的契约设计,即对外提供的业务能力。
  • 服务内部要保持高度模块化,才能够容易的被拆分。
  • 可测试。

二、如何安全地持续地拆?

系统已经上线大量的用户正在使用,如何在不影响当下系统运行状态的前提下,持续安全地演进?其实持续演进就是一场架构层次的重构,在这样的路上同样需要:

  • 坏味道驱动,架构的坏味道是代码坏味道在更高层次的展现,也就意味着架构的混乱程度同样反映了该系统代码层的质量问题。
  • 安全小步的重构。
  • 有足够的测试进行保护——契约测试。
  • 持续验证演进的方向。

三、如何保证拆对了?

拆并不是一件容易的事,有诸多的因素。我认为不管表象是什么,拆之前需要弄清拆分的价值所在,这也是我们可以保证拆分结果的源头。拆并不是一件容易的事,有诸多的因素。不管表象是什么,拆之前需要弄清拆分的价值所在,这也是我们可以保证拆分结果的源头。

 

参考书籍、文献和资料:

【1】http://insights.thoughtworkers.org/service-split-and-architecture-evolution

相关推荐
©️2020 CSDN 皮肤主题: 点我我会动 设计师:白松林 返回首页