通过本篇文章您可以了解到以下内容:
- Monolithic到Microservices的思考（回顾）
- 应用现代化策略的评估和规划
- 应用现代化策略的5R模式
- 微服务架构设计的最佳实践
- 总结
Monolithic到Microservices的思考（回顾）
首先让我们做一个简单的回顾：
- 本系列文章的第一篇向大家详细介绍了Monolithic 架构的优势、劣势，以及阐述了从Monolithic 架构演进到Microservices 架构的原因。
- 本系列文章的第二篇向大家详细介绍了Microservices 架构的优势以及大家普遍采用微服务拆分设计的理论指导原则（Domain Driven Design）
通过之前两篇文章的介绍，相信大家对无论是Monolithic 架构还是Microservices 架构都有了一个较为清晰的理解和认知，同时大家可能也会存在一些疑问，例如:
- 既然微服务架构具有诸多优势，那么在应用现代化改造的过程中是否将所有的传统巨石应用都要进行拆分、改造成微服务架构呢?
- 如果对于上一点提出的问题回答是否定的，那么判断衡量的标准又是什么呢?
- 对于不拆分、改造成微服务架构的传统巨石应用，它们应用现代化改造的最佳实践是什么?
- 对于需要拆分、改造成微服务架构的巨石应用，这种拆分、改造的最佳实践又是什么?
接下来让我们带着上面的这些疑问，走进今天的内容。
应用现代化策略的评估和规划
在应用现代化道路上，我们首先想的不是用什么技术框架、也不是传统巨石应用怎么进行拆分，改造成微服务架构，而是在我们已知改造范围的前提下，从技术和业务角度进行评估和规划改造的优先级。
如上图所示，从技术和业务角度分别罗列了需要考量的因素。从技术方面涉及到了目前使用何种技术框架、是否使用了专有的工具、系统集成、依赖程度等因素。在此阶段我们可以通过一些工具来帮助我们进行有效的评估，这里面包括手动分析工具，以及自动扫描工具等。
（手动分析SNAP表格）
SNAP一种有效的手动分析工具，首先通过不同语言技术栈创建不同模版，在模版中会包含诸多技术因素，以Java为例，例如JDK版本、缓存（Caching）使用何种技术、编译工具（Ant、Maven、Gradle等）、代码测试覆盖率、数据访问模式（ORM何种技术框架）等因素。通过一系列因素的填写，判断，最终会得出一个分数，分数代表了改造的难易程度。
相比SNAP手动分析的情况，在可以获取源代码权限时，我们可以采用自动化扫描工具VMware Cloud Suitability Analyzer（简称CSA）。CSA扫描规则采用yaml方式进行编写，根据编写规则，CSA会对应用进行扫描，并最终会得到技术改造成本高低的分数（云亲和性），通过此分数，我们可以很好的从技术角度进行判断，举个例子，如果使用EJB和使用Spring Boot这两种不同的框架，改造的成本是大大不同的。
（VMware Cloud Suitability Analyzer）
另一方面，从业务维度涉及到了我们改造后带来的收益是什么?改造过程的风险又有多高?这个应用系统对应的业务重要程度又是怎样?业务变更频率等因素。
应用现代化策略的5R模式
在上一章节我们了解到，通过技术、业务角度进行评估并非所有传统应用在现阶段都适合进行拆分、改造成微服务架构。根据评估和规划，我们可以把传统应用进行应用现代化改造归结为5种方式。如下图所示:
我们首先来看看关于Retire、Retain、Rehost的解释。
Retire
核心关键词“退役”，顾名思义这一类应用停止开发、维护，并由新的SaaS解决方案进行替代。
Retain
核心关键词是“保持现状”，这一类应用并不会进行迁移改造（上云）而是继续交给团队进行本地优化和维护。之所以出现这类情况的原因很多，例如迁移改造成本过高等因素。
Rehost
核心关键词是“转移、挪动”，这一类应用会从本地迁移到云上进行托管，即可以理解为由现有本地物理机和虚拟服务器上进行部署转移到云上IaaS解决方案的过程。值得注意的是Rehost可能会促进未来应用架构的升级、改造。
接下来是Replatform和Refactor，这里我们重点讨论下这两类模式。
Replatform
适用于业务功能相对固定、无需改动的应用系统。这种方式的特点是少量改动与外部依赖的相关代码以及少量修改相关配置。以镜像方式进行部署、运行在Kubernetes中。虽然改动会带来一些成本的增加，但是通过这种改造，可以享受到云原生带来的部分技术红利。
Refactor
适用于业务功能持续变化、更新较为频繁的应用系统。这种方式通常的做法是重构、拆分现有的巨石应用，并设计成微服务架构，同时采用云原生的相关技术。
需要注意的是，在Refactor模式下，我们需要将传统应用进行拆分、改造成微服务架构。接下来就让我们看看微服务架构设计的最佳实践是什么?
微服务架构设计的最佳实践
整体来说微服务架构设计包括两大方面，技术方面、业务方面。
对于技术方面:
我们可以理解为在已经拆分好微服务的基础上，通过选定的技术框架进行落地实施。以Java技术栈为例，我们可以通过Spring提供的全家桶解决方案Spring Cloud来帮助我们构建微服务架构，亦或使用Spring Boot并结合Kubernetes进行构建。至于Spring技术体系的相关内容，本章节不做过多说明，后续的文章中会向大家进行详细的介绍。
对于业务方面:
我们可以理解为根据业务实际情况如何进行微服务的划分。VMware在进行微服务架构设计方面，是采用SWIFT方法论，是由Pivotal在2016年创造出来的。
接下来让我们看看什么是SWIFT?
SWIFT定义:
SWIFT是一种轻量级、敏捷、高效同时又快速的将单体巨石应用拆分、转化为微服务架构的方法。SWIFT从业务领域分析入手，逐步过渡到架构设计。以Workshop对话的形式进行，同时融合了领域驱动设计（Domain Driven Design）的思想和原则，整个过程更多的是引入了白板、贴纸等可视化元素，促进各领域专家、技术、管理等多角色人员共同参与和协作。
既然SWIFT是一整套的能够落地的方法，那么它的流程是怎样的呢?
（详细信息参考: https://tanzu.vmware.com/deve...）
从图中可以看出整个SWIFT流程概括为七个步骤，这里面着重介绍下Event Storming、Boris Workshop、Snap-E、Thin Slice步骤。
Event Storming
事件风暴（Event Storming）快速发掘和梳理业务流程，形成业务边界、初步的微服务划分，并形成统一的业务语言。
Boris Workshop
生成应用系统的概念型微服务架构，确定应用系统交互方式（同步、异步）
Snap-E
在进行Boris的同时，实时的记录下每个微服务的要素，这些要素包括（API、DATA、PUB/SUB、STORIES、UI、RISK）。
（真实场景）
Thin Slice
一个薄切片（thin slice）指的是一个短的领域事件流，通常是对于最终用户有意义的一个端到端的业务流程。
总结
回顾全篇内容，整体包括以下三方面内容:
- 首先回顾了Monolithic 架构和Microservices 架构，并引申出既然微服务架构具有诸多优势，那么是否在应用现代化改造的过程中，将所有传统巨石应用都需要立马进行微服务架构的改造等一系列疑问。进一步了解到，我们需要做的是通过合理、科学的手段进行应用现代化策略的评估（技术、业务两个维度），同时在评估完成后，会进行对应5R模式的归类。
- 其次对于应用现代化策略的5R模式进行了解读
- 最后针对于Refactor（传统应用重写、改造成微服务架构）这种情况，进行了详细介绍，这其中包括SWIFT方法的定义、实践流程等。
同时在SWIFT方法中的Event Storming、Boris Workshop、Snap-E又可以理解为从业务角度微服务架构设计的三把利器。那么作为利器之一的Event Storming具体实践流程的细节是怎样的? 又有哪些参与人员? 在这个实践过程中又会结合使用哪些工具?对于上述问题，在下期的文章中会继续和大家进行交流分享，敬请期待! 如您有任何建议，欢迎随时联系我们!
参考链接:
1.https://tanzu.vmware.com/appl...
2.https://github.com/vmware-tan...
3.https://tanzu.vmware.com/deve...
作者简介
李刚，VMware 大中华区应用现代化部门高级系统架构师，资深企业级软件开发和软件系统架构师。Spring Cloud开源社区项目贡献者、Netflix开源社区贡献者。近几年，参与并主导了许多大型企业客户的应用现代化数字转型项目，涉及物流、制造、金融等诸多领域。特别对微服务实现方法、现代化应用架构设计、云原生实施落地、开源软件技术等方面有着丰富经验。
来源｜公众号：VMwareTanzu云原生