| 编辑推荐: |
本文主要介绍了通过5步法指导思想来建设中台架构：业务抽象、高阶设计、组件建模、持续交付、持续运营。希望对你的学习有帮助。
来自于简书，由火龙果软件Linda编辑、推荐。 |
|
概述
这里通过5步法指导思想来建设中台架构。
1. 业务抽象
在业务抽象阶段， 通过业务调研和业务分析， 设计业务蓝图和抽象业务元素， 为下一阶段的中心建模阶段准备顶层思想和业务素材。
业务调研：
以面向中心的思想来探讨业务， 认为业务流程只是形式， 核心是各领域中心的结构和运行机制。在业务调研过程中进行领域模型的探讨，
反复思考逐步清晰业务领域的边界。
顶层业务分析：
在业务调研结束后， 结合行业趋势、 类似项目的比较以及自身的经验， 输出企业的商业模式和核心业务场景。
业务场景包括企业级业务场景、 部门级业务场景和操作级业务场景。 并在业务场景梳理过程中， 找出企业痛点。
最终设计出企业TO-BE的业务蓝图和应用蓝图。
业务抽象：
通过顶层业务分析， 明确了总体方向后， 我们便可以展开对具体业务场景的梳理和抽象， 并输出功能需求清单。
在此过程中， 还需要定义出功能操作的业务对象或业务实体。 基于业务实体， 结合对应的功能需求， 定义出需要系统提供的能力。
根据能力的主题和实体间的密切关系， 我们便能对实体进行归类， 定义出主题域。
2.高阶设计
（ 1） 中心规划
经过业务的调研和分析， 技术架构师理解并熟悉了业务。 基于上阶段输出的主题域， 技术架构师按照中心的多个划分标准，
进行中心的规划。
（ 2） 0级架构设计
业务中台的0级架构本质上是应用架构， 它以中心为最小单位进行设计， 因此也称为整体架构设计。0级架构包括了功能层级的架构和技术层级的架构。
功能层级的架构需要描述业务中台在整个数字平台中所处的位置， 业务中台由哪些中心组成， 以及中心与应用、
中心与后台的交互关系。 功能层级的0级架构承接了企业的应用蓝图规划， 指导企业各IT系统的职责划分和定位。
2.1功能层级
企业整体功能架构从下往上分为IaaS层、 PaaS层、 基础组件层、 数字中台
层（包括业务中台和数据中台） 和业务应用层。 每一层的具体功能如下：
功能层级的0级架构示意图
IaaS层： 完成硬件资源的虚拟化管理， 为用户提供对资源的使用服务。
PaaS层： 为应用软件提供部署平台和运行环境。
基础组件层： 介于业务服务和技术中间件之间， 提供通用的业务功能和技术功能， 并解耦业务应用和技术中间件。
数字中台层： 分为业务中台和数据中台， 实现企业业务活动的核心机制， 并通过数据中台对业务运营提供指导。
业务应用层： 通过调用和组合中台能力， 实现应用逻辑。
2.2技术层级
技术层级的0级架构需要说明各系统、 各中心分别使用什么技术来实现，
以及整个体系的技术分层， 如下图所示：
技术层级的0级架构示意图
技术架构总体上分为展现层、 服务层、 接口系统、 运营管理和运维支撑：
展现层与服务层相分离， 展现层采用当下主流的前端框架， 分别对移动端、 PC端进行支撑。 通过合理的技术搭配人性化的设计满足用户感官体验需要。
服务层的架构采用分布式的微服务架构， 微服务架构去中心化加强终端的特点， 让服务免去雪崩效应等容灾上的风险。
同时， 整体技术架构具备易于扩展、 组合、 部署， 可支持动态伸缩、 精准监控， 并且可以提供灰度发布等优点。
服务层包含应用服务、 中台服务、 技术服务。 应用服务与中台服务都以微服务架构实现。
技术服务又分为PaaS层和IaaS层： PaaS层通过各项基础中间件的能力向上层输送搜索引擎、 分布式文件存储、
分布式数据库、 分布式缓存等能力； IaaS层向用户提供基础资源服务。
运营管理通过埋点技术、 A/B测试技术、 大数据技术来进行数据采集分析和业务试错， 并通过计算结果来指导业务工作。
运维支撑将从底层对所有服务做支撑。 运维体系通过对基础设施的监控、 服务升降级等措施来确保系统的容灾能力与稳定性。
（ 3） 中台核心数据流规划
为了简化业务流程， 根据前期的业务分析， 结合0级架构的设计， 我们可规划出企业的业务数据流（以房屋租赁行业为例，
多业态） ， 如下图所示：
基于中台的业务数据流
客户中心承接前台应用租房、 买房客户的注册信息； 对于集团多业态的业务特点而言， 经纪人、 物管人员、
企业员工都是企业客户， 都应该进行精细化管理。 客户中心为统一认证提供账号、 密码的验证， 为各应用提供客户的全局唯一标识。
产品中心接收来自 ERP的工程域楼盘信息、 员工录入或经纪人提供的可租楼盘营销信息， 形成每一间房的完整且统一的档案。
为前台各应用提供全方位的楼盘信息， 包括工程信息、 营销文案信息和房间信息。
交易中心接收来自 WMS的库存信息， 完成购房订单的生成、 在线租房的交易等业务活动。 订单生成后，
根据订单中的商品向WMS发起发货指令。
3.组件建模
（ 1） 产品设计
产品设计是在业务顶层设计的指导下， 逐层往下抽象的过程， 主要是将业务调研的成果转化为产品原型和需求规格说明书（主要由业务场景、
业务流程构成） 。
中台产品的详细设计需要以面向中心为指导思想。 不仅需要设计出应用需要实现的功能， 更重要的是要将需要中心支撑的功能明确标识出来，
归到中心的待实现列表里。 这样技术工程师在领域建模阶段才有具体和明确的输入。
建设中台的核心目 的不是为了共享， 共享只是中台的特性。 中台是为了完成业务的核心运行机制，前台提供业务能力基础的系统。
（ 2） 组件模型设计
组件模型设计承接0级架构设计， 是对中心内容的展开。 通过对中心功能的分析和对中心业务实体的抽象，
将具有较强依赖关系的业务实体聚合为一个组件， 或者将具有相同主题的业务功能聚合为一个业务组件。 最后以结构化的形式聚合这些组件，
构成中心。
如何判断组件模型是否合理呢？ 是否很好地支持业务流程、 业务场景、 复杂的业务规则是衡量组件模型优劣的标准。
我们可以通过穷举边界业务场景的方法， 来反证组件模型设计是否合理。
最后需要强调一点， 组件是可以独立为微服务的， 只要符合微服务的条件， 就可以独立。 但是在实践过程中，
如果微服务承载的业务规模不大， 独立带来的业务价值不高， 反而会增加运维成本。
（ 3） 1级架构设计
组件模型设计完成后， 需要将模型转化为应用架构。 这里的应用架构是指中心内部的应用架构，
我们称为1级架构。 1级架构是以组件为最小单位设计的功能层级的架构。 1级的功能架构是必不可少的，
它指导着我们的设计和开发； 技术层级的1级架构可视情况而定， 如果技术内容比较复杂则需要输出。
某企业功能层级的交易中心1级架构
（ 4） 关键交互图设计
前面已经完成了 0级和1级的架构设计， 有什么方法能证明设计是否可以满足实际业务场景的需要吗？ 可以通过实现业务场景的动态交互图，
来反向论证设计的合理性。 如何判断动态交互图是否合理呢？ 根据业务逻辑是否清晰、 流程是否简洁、 客户交互是否高效来判断。
如果设计出的交互图不合理， 那就说明0级或1级架构存在设计不合理的问题。 另外， 通过交互图还可以较好地将设计思想传递给开发团队。
4.持续交付
我们主张采用敏捷的方法进行开发交付， 将最终目 标拆解为多个小目 标， 逐个完成。 同时又将每个小目
标拆为多个子项目 ， 每个小团队各自 负责一个子项目 ， 所有团队并行开发， 协同向前推进。
（ 1） 迭代规划
将项目的最终目 标拆分为几个阶段性小目 标， 每个小目 标都能上线交付。 这里强调一下， 每个小目标都是一个闭环，
是一个端到端可验证的交付物。 在这个阶段， 需要定义好可交付的标准， 而不是开发人员常说的开发完成，
我们主张是集成部署验证后， 才能算作达到可交付的标准。
（ 2） 需求反讲开发
任务确认后， 要求开发人员反讲需求， 并给出对应的技术解决方案。 团队讨论通过后， 进行开发。
（ 3） 持续集成交付
敏捷方法强调开发完成的代码能够立即提交， 自动构建测试， 强调立刻处理代码冲突并验证。 验证的过程强调自
动化测试， 对可能出现的问题进行预警反馈。 集成测试通过后， 能够自 动将代码部署到类生产环境中，
交由用户和质量保障人员验证。 这里要强调的是， 保障代码的每一次改动都能在任何时候部署到环境中。（
4） 回顾总结调整
在每一次迭代完成后， 团队及时组织召开总结会议。 回顾本次迭代在技术、 组织、 沟通方面表现优秀的成员，
学习先进的技术和方法。 总结错误和阻塞的问题， 针对性提出改正的措施， 并在下一次迭代开始前， 做好对应的调整和准备。
5.持续运营
项目上线后， 只是产出业务价值的开始。 数字中台需要在持续不断的运营中， 不断沉淀和发展。 能力会逐步增强和扩展，
模型会逐步调整和完善。
（ 1） 业务运营
通过数字中台的能力， 我们可以调优传统的业务流程或者尝试新的业务场景， 并且反哺数字中台。
（ 2） 内容运营
内容运营主要是指通过企业自 营渠道、 第三方流媒体等电子渠道来建立与客户的连接。 连接内容包括向客户推送企业新品介绍、
促销活动宣传、 企业动态等。 数字中台完成内容管理、 推送逻辑管理。
（ 3） 技术运营
为了更好地发挥数字中台的作用， 需要支持灵活的业务运营和内容运营。 因此， 数字中台需要不断运用技术栈或反复调整技术参数来适配，
常见的有A/B测试技术的使用和策略调整， 以及弹性伸缩技术、限流降级技术的使用等。 这些内容都属于技术运营的范畴。
（ 4） 数据运营
在线业务需要数据中台的反馈和指导， 因此数据中台需要对业务数据进行分析和挖掘。 而分析的维度和挖掘的算法需要不断地补充调整以及优化，
数据运营则完成这些调整和优化任务。
|
