云原生应用架构的迁移 一 ：增量迁移范式

[魏小言]

云原生应用架构的迁移 一 ：增量迁移范式
云原生应用架构，以快速创新、服务弹性扩展、持续交付价值的特性，使企业产品服务在市场中具备真正敏捷的竞争力！

拆分原架构，迁移上云
前篇文章介绍了 云原生应用架构中的技术变革 三：从集中专治到分散化 ，大家读了之后会觉得：“ 太棒了，品完就想立马结合手上的资源 Try 一 Try ! ”

那么就可能会有这样的问题，在分解数据、服务和团队后，要如何拆分已有的单体应用并把它们迁移上云呢？

增量范式
如何拆分已有的单体应用并把它们迁移上云呢？

答案就是，增量范式。

这种范式在过去的各种尝试中脱颖而出，在迁移效能中是佼佼者，SoundCloud 和 Karma 就是最棒的例子！

下面将一步一步介绍如何利用增量范式进行迁移上云…

新功能微服务化
大家是不是很迷惑，为什么第一步是 “ 新功能微服务化 ” ？

因为从头开始构架一个服务比分解一个单体应用并重构服务相对容易和快速的多！所以不要继续再向单体应用中增加代码，将所有的新功能以微服务的形式构建。

注意：当然这是假设当前服务仍需要继续添加新功能的场景，若不需在继续添加，则可以跳过这部分。

那么我们在构建微服务架构的时候最需要注意的是什么呢？或者说我们构建新服务怎么与单体服务进行交互呢？

整体来说有两点：

服务交互
服务集成
大家可以回想一下团队用的 RPC 框架，尤其是支持跨语种、多种协议的框架。不管其内部如何实现，核心点是：通信协议、领域模型转换！

既然我们知晓了关注点，那么如何入手呢？

隔离层
我们需要一个环境提供给我们进行新老服务集成交互，我们往往把这个环境叫做 “ 隔离层 ”。

Eric Evans（Addison-Wesley）在领域驱动设计（DDD）中讨论了隔离层的思想， 其目的是允许两个系统的集成，而隔离层不仅仅提供环境，还确保一个系统的领域模型破坏另一个系统的领域模型。

毕竟我们不希望新功能集成的微服务，与单体紧密结合，让他们肆意地深入单体的内部结构，这也是隔离层名字的由来。

在隔离层中，我们主打三个关注点：

系统集成
通信协议转换
领域模型转换
针对三点，隔离层分别提供了解决方案：表现层、适配器、转换器。

表现层
表现层目的是简化应用接口之间的集成过程，独立于单体及新微服务内部逻辑上层，有明确的上下界，统一的上下层交互。

结构可类比七层网络的表现层、 MVC 结构的 Model 层、等等

适配器
适配器，就是 三十二种设计模式之一 的适配器模式。通过适配器模式来定义功能 Service/Interface ，来提供我们需要的新功能。

它知道如何获取系统请求，并使用相同协议将请求发送给单体应用的表层。

转换器
转换器的职责是在新微服务、单体应用之间进行领域模型的转换，确保双方数据交互畅通。

扼杀单体应用
有了隔离层，增量迁移的第一步：新微服务化 已完成。下一步就是 “ 扼杀单体应用 ”，将在下篇博文继续介绍！

Q&A
1、增量模式，手段似乎与 “ 系统重构 ” 要素相似，有什么联系吗？

对，此模式在 “ 系统重构 ” 中也有应用。
两者目的相似，毕竟架构迁移也是系统重构中的一种！

2、文中的领域模型是指什么？平时不见这种名词…

领域模型，计算机科学中的名词。泛指系统的架构/结构，具指系统的数据结构，不同语境语义不同，大家以经验定性即可。

附录
产品测试是使设计决策得以贯彻执行的必要手段！

[魏小言]

nice