广大组织机构和企业通常都拥有极为庞大的整体式应用，为业务需求提供服务和支持。这些应用普遍僵化，在开展维护活动和实施业务快速转型或改进所需的变更时，往往难以处理。整体式应用的变更需要重新构建和重新编译代码库，但由于组件之间错综复杂的相互依赖关系，在实施和部署这些变更期间，可能会影响其他服务和组件。影响程度与应用的规模成比例。此外，通常需要停机才能部署新版本的应用，这可能会影响上市时间。
至关重要的是，必须对风险加以衡量，并透彻了解将整体式应用转变为微服务所带来的开发和运营方面的复杂难题。微服务需要组织方面的变革，例如，按每项微服务以及开发和运营微服务方面的特殊技能，将开发团队分为多个小团队。仔细考量方方面面的影响并认清转型的价值之后，即可将本博文用作为转型指南。
面向微服务的转型之旅
应用分析
开始细分整体式应用之前，架构设计师或开发人员必须对应用进行分析。首先要了解应用的功能。应用功能代表了业务和技术需求。这些功能可分为多个领域。本文将以电子商务网站的结算应用为例。用户搜索商品，并且可能会进行比价，然后将所选商品添加到购物车中。购物流程结束时，用户将对商品进行结算。在此阶段中，将显示并计算即将购买的商品清单、每个商品的单价、总价和增值税费用。图 1 显示了执行结算的整体式应用。请注意，其中的应用充当执行并提供所有必需数据的黑盒。
图 1：结算应用显示为整体式应用
领域驱动设计
了解整体式应用后，下一步是将此应用分割为多个领域。领域驱动的设计是一种软件工程方法，旨在绘制出应用组件的上下文界限。在“结算”示例中，这些领域可以是供应商、承运方和支付。例如，供应商领域涵盖了库存可用情况和商品特征。又如，承运方领域包括运费。最后，支付领域可能会涵盖总价和增值税费用计算。
图 2：在结算流程中应用领域驱动设计 (DDD)
这些领域可帮助定义上下文界限。上下文界限聚焦于创建孤岛式环境的业务陈述。通过使用上下文界限，可定义每个团队的工作范围。这意味着可根据这些上下文来划分整体式应用的团队（业务、运营、开发等）。
剥离关联的组件
下一个阶段是为每个已定义的领域创建剥离关联的独立组件。每个组件都致力于满足一种业务需求。这样即可满足“单一职责原则”，即每个组件只有一个变更理由。换言之，每个组件都代表最基本和最简单的业务需求。这项活动的主要目的是将代码库细分为多个剥离关联的组件。
图 3：识别支付领域的独立组件
在此阶段，整体式应用的逻辑微服务表示正变得越来越清晰。现在的问题是，从何处开始重构？通常，存在两种类型的应用重构：大爆炸式重构和阶段性重构。大爆炸式方法需要开发与现有旧系统相互独立并隔离的微服务。在部署完整结构之前，代码未在生产中进行测试。阶段性方法与此相反，可对应用中小型的独立部分进行改造；经历多个阶段，直至将应用替换为多项微服务。它可灵活适应，从而充分发挥这种方法的优势。在本文中，将对结算应用采用阶段性方法。
边缘服务
剥离关联的组件与其他组件和服务存在依赖关系。转型期间必须对这种依赖关系加以考量。因此，建议从边缘服务开始处理。边缘服务是只需最低限度的逻辑、基本路由以及与其他服务之间保持最低限度依赖关系的服务。支付授权即为边缘服务的一个示例。支付授权通常由第三方执行，如银行或信用公司。此外，支付授权作为模型可供环境内的其他系统（例如，订阅）复用。它是一项独立服务，可从应用中抽取出来，而不会影响代码的业务逻辑。因此，它最大程度降低了业务影响的风险。
认清边缘服务之后，必须构建此服务的接口。接口用于定义通信的方法和服务的交互。下图解释了从应用中抽取边缘服务后的交互情况。
图 4：从结算中剥离支付授权模块的图示
小结
总之，整体式应用需要从领域角度加以分析。这有助于识别应用改造的目标领域。通过使用领域驱动设计 (DDD) 来创建应用的上下文边界，可帮助充分认识应用领域。领域中的各项功能可细分为多个剥离关联的组件。分析组件之间的依赖关系是非常重要的。因此，需要将整体式应用转变为微服务时，建议从边缘服务开始。
如果你想了解更多，可以加群：855355016，群内有Java高架构师、分布式架构、高可扩展、高性能、高并发、性能优化、Spring boot、Redis、ActiveMQ、Nginx、Mycat、Netty、Jvm大型分布式项目实战学习架构师视频免费获取
网友评论