23,634
社区成员
发帖
与我相关
我的任务
分享云原生应用架构的迁移 二 ：扼杀单体
# 云原生应用架构的迁移 二 ：扼杀单体
云原生应用架构，以快速创新、服务弹性扩展、持续交付价值的特性，使企业产品服务在市场中具备真正敏捷的竞争力！
上篇介绍 [云原生应用架构的迁移 一 ：增量迁移范式](https://blog.csdn.net/qq_34417408/article/details/120241189) 应用上云的第一步，就有小伙伴问了，**“ 无需新功能的应用需要怎么做迁移呢？”**
今天来解答，这种疑问的同学可以跳过第一步，直接进行**第二步：扼杀单体** ！
### 分解应用，抽微服务
在原始森林中的藤系植物，有着与众不同的生活法则，它们缠绕在树干上，锋利的根系深深刻划在树体，分分秒秒汲取养分。随着漫长的生长周期，树干逐渐干枯，直至被扼杀！
>这个法则同样适用于我们架构迁移，围绕旧系统边缘的新系统，让它几年来慢慢增长，直到旧系统被扼杀。
当新微服务已经和原单体可以顺顺利利的交互时，我们就需要考虑下一步，如何从单体中抽象出新的微服务，进一步瓦解单体，直至扼杀！
我们为如何抽象新微服务提出两点建议：
- 分解服务标准
在 [为何使用云原生应用架构 二 ：独霸天下之四大绝技](https://blog.csdn.net/qq_34417408/article/details/118254217?spm=1001.2014.3001.5502) 中有关于微服务的介绍，服务定义是具有上下边界内部一致的最小服务单元。
我们需要在单体中识别区分领域模型内部一致且上下界完整的功能服务，那么这些服务就是我们分解的候选单位。
- 分解优先级
那么多的候选单位中，我们优先进行哪部分的微化呢？
这个可以从我们迁移的目的之一出发：快速创新。
我们需要考量先对哪部分动手，使我们最大、最快受益，短时间获得最优的 ROI 。
### 扼杀终结
拥有了服务分解的优先级和服务微化的手段，那么什么样的状态意味着我们迁移完成呢？
可能有同学会说，“ **当然是原单体服务不在支持任何生产服务的时候** ！”
不错，当单体结构全部上下界都被微化，不在支撑任何服务，我们就可以消除隔离层，新服务雄起。
这里补充一种 “ 扼杀终结态 ” ：
**从实际生产考量，完成迁移并不以为着服务完全扼杀：当额外服务提取的成本超过必要开发努力的回报时，我们就可以考虑提前结束。**
>毕竟迁移这部分价值不大，且维持必要的隔离层成本足够低。
### 新服务崛起
完成迁移不仅仅需要手段方式，更需要耐心处理系统各个结构编排，且根据自身实际，结合理论经验数据，才能搭建适合自己的云架构。
>到这里，云原生应用架构系列博文暂且到一段路，感兴趣的同学可关注后续，或私信博主技术交流，希望大家每天都有所不同！
## Q&A
1、文中大都是理论知识，博主可以举个具体的例子吗？
>理论由实践而来，具体例子有，整理起来需要更多精力，后续整理出来补文。
## 附录
每天不一样，样样精彩！
...全文
