中文
English
文：戴敏
腾博tengbo9885官网信息金融科技首席架构师
前言：
可以通过实验营业组件化来避开数字化转型焦油坑 ，详细而言就是建设“营业迅速性组件基础设施” ，包括营业组件及其支持组件。前面文章形貌了一种可参考的营业组件的系统 ，这个系统可以以为是一个高阶的看法性设计的效果 ，通过营业能力、营业领域、服务域的剖析、设计可以开展后续的开发事情 ，而开发事情围绕对API的详细设计睁开。
鉴于营业组件系统涵盖的事情内容较量多且重大 ，本文讨论了一种可参考的落地实验计划 ，主要包括2个阶段和1个支持：2个阶段是营业组件蓝图设计阶段、营业组件设计开发阶段 ，1个支持即架构设计的支持。
一、营业组件化实验计划
1、营业组件蓝图设计阶段：
营业组件蓝图明确展示出多级营业领域、服务域的位置 ，以及服务域之间的可用服务关系 ，包括总体图和场景图。
? 场景图：
场景图中包括场景涉及的服务域及服务域之间的服务毗连 ，服务毗连只针对场景下的可用服务毗连而非所有可用服务毗连；体现的服务毗连在营业组件开发中映射为API服务端点之间的挪用。场景图的理想设计模式是分层架构 ，即 ，场景图可以通过组装响应更高一级的营业场景。主要展示如下内容：
1）体现涉及的所有服务域；
2）体现场景中每个服务域的活跃状态时间 ，即营业工具在营业运动处置惩罚时代的状态；
3）体现服务域之间服务依赖关系 ，即先后、并行等 ，以及明确的服务消耗方和服务提供方；
4）体现服务消耗的同步响应、异步响应 ，异步响应应体现出响应点；
5）体现服务消耗的行动 ，标准HTTP动词+行动标识；
6）体现服务交互的要素或文本。
2、营业组件设计开发阶段：
以营业组件蓝图为基础举行营业组件设计事情。
? 服务域设计：
使用面向工具设计要领 ，围绕营业工具及营业行为举行设计。为了配合后述的架构设计支持 ，服务域设计中需要关注：
1）服务域交互的所有信息都应该体现在设计中 ，这些信息可能影响系统架构对事务的触发；
2）服务域设计应包括事务设置文件的设计 ，包括关联到要害信息项、信息属性的触发逻辑和触发阈值；
3）服务域设计应包括服务协议界说 ，包括触发服务域的战略、阈值的界说、服务性能的界说、服务完整的输入输出信息的界说、清静控制信息的界说；
4）服务域的容错处置惩罚：例如针对延迟、过失请求的处置惩罚 ，也可以包括类似优雅降级的处置惩罚；
5）服务域处置惩罚的幂等性设计 ，其中应该思量服务域处于并行处置惩罚情形中的幂等性。
? 服务域服务操作设计：
服务操作设计需要包括几部分内容：
1）服务域的焦点功效：服务域封装的营业工具的焦点营业功效；
2）服务操作的行动：例如初始化、更新、检索信息等；
3）每个服务操尴尬刁难应到API的一个服务端点；
4）在实现中 ，服务操作可能需要举行细粒度的剖析 ，剖析为差别的端点 ，这种剖析也用于过失、异常等的处置惩罚；
5）应体现出服务操作的细节 ，例如新闻 ，关于遗留系统可能尚有新闻负载的需求；
6）应体现出新闻头、清静处置惩罚、过失处置惩罚、新闻索引等附加内容。
3、架构设计的支持：
架构设计应支持营业组件系统 ，与普遍的架构设计相比要害的问题之一是对编排的支持计划的选择。通常有2种编排要领可以选择。
一是通过专门的自力编排逻辑来实现：服务域以类似服务中心的方法构建 ，编排逻辑笼罩各个服务域之间的服务挪用 ，由其包管营业操作的可重用性。但自力的编排逻辑也相当于建设了受限的重用路径 ，新的营业行为通常也需要特另外设计、开发事情。
二是通过事务驱动的编排：服务域通过事务自动响应 ，对自身支持的营业行为举行处置惩罚。当营业操作需要其他服务域举行响应时 ，系统架构支持服务域之间触发一系列事务 ，每个服务域针对自己关注的事务举行响应执行所需的州操作。
更合适的营业组件系统是事务驱动的编排架构 ，这样的架构能够支持营业组件系统更好地实现无邪性和弹性。但事务驱动的编排需要设计更重大的架构 ，例如支持服务的异步级联 ，消耗方服务域触提倡事务后 ，服务提供方的服务域响应事务 ，整个级联直到所有的服务提供方都完成处置惩罚后才竣事。这样的异步架构还需要思量服务状态的同步 ，例如串、并、串的组合场景 ，和整个处置惩罚事务的控制 ，例如通知、中止、自动超时等 ，而关于执行要害路径上的服务域只要在允许时间内完成即可（非要害路径上的服务域则差别）。
系统架构还应支持事务设置文件、服务目录、数据存储、事务日志、运行数据处置惩罚、事务一致性、路由等。
二、遗留系统的组件化
营业迅速性组件基础设施需要解决遗留系统的问题。遗留系统通常由于基础架构层面的限制而缺乏无邪性 ，例如：单体架构 ，但通常包括了大宗经由验证的营业能力 ，彻底组件化重构这些营业能力往往需要较大投入。通�？梢允褂谩耙帕粝低辰噬薄钡慕饩黾苹蛘摺罢攵砸帕粝低车奶厥庹铰孕愿纯獭钡慕饩黾苹� ，本文主要从组件化角度讨论遗留系统的解决思绪。
通过对遗留系统举行组件封装的方法 ，实现遗留系统的组件化 ，目的是使其能够在营业组件系统中正常运行。举行组件封装后的遗留系统也基于组件架构运行 ，因而也提升了遗留系统在与其他服务域举行组适时的弹性和无邪性。由于是封装模式 ，遗留系统内的弹性和无邪性照旧大部分取决于系统自身。封装的实质是为遗留系统设计确定的组件界线和上下文 ，在实践中可以将一个遗留系统划分为多个组件界线。封装需要体现在蓝图、组件开发阶段中 ，通过这种方法也可以镌汰遗留系统在组件系统中的运行缺陷。
组件封装差别于以往 ，需要从营业工具及其相关的营业行为出发对遗留系统举行组件界线和上下文的划定 ，这相对以往而言事情量更大些 ，但利益是这种组件界线的划定在组件系统中是相对稳固的 ，在遗留系统生命周期剩下的时间中禁止易爆发转变。此处的问题是 ，需要在实验中团结企业的营业妄想 ，评估哪些遗留系统更适合彻底重新建设而非举行组件封装 ，团结其在组件蓝图中的位置来剖析将有助于评估。
在实验中 ，遗留系统组件化的重点是关于原有的后端高并发类的事务处置惩罚系统的组件封装 ，这些系统对整个组件系统的运行质量/效果影响更大。
本系列文章至此完结 ，主要剖析了数字化转型焦油坑及阻止焦油坑的主要行动：营业组件化。我们谈到了营业迅速性组件基础设施 ，并重点针对其中的营业组件举行了剖析和叙述。关于营业组件系统 ，我们谈到了其主要的几个要素：营业能力、营业领域、服务域、API。最后 ，我们讨论了营业组件化的落地实验要领。
随着数字化转型的深入 ，行业里对其的思索和实践也大部分最先转向理论指导下的种种立异 ，数字化转型的重大性越来越高 ，对目的及现实效果特殊是对营业战略支持的效果审核比重也越来越重 ，迫使我们必需正视数字化转型中众多的焦油坑。这些焦油坑消耗了大宗的企业实验本钱 ，且对实验效果爆发了较大的负面影响。为此 ，特整理了可参考的实践和思绪。
所有的剖析和讨论都以当下的新手艺系统和能力为基础睁开 ，代表了作者20多年的应用软件开发履历 ，及对前沿行业实践、手艺理论的学习和思索。由于篇幅所限 ，许多问题没有细化睁开 ，将适时继续睁开探讨 ，期待与各人相互交流、分享履历。
滇公网安备53010302001382
