数据中台与业务中台总体技术架构设计方案

数据中台与业务中台总体技术架构设计方案整理制作：郎丰利1519制作时间：2023年睿利而行整理制作：郎丰利1519制作时间：2023年睿利而行整理制作：郎丰利1519制作时间：2023年睿利而行2023年目录CONTENT总体技术架构思路01总体技术架构设计02中台设计03整理制作：郎丰利1519制作时间：2023年睿利而行整理制作：郎丰利1519制作时间：2023年睿利而行整理制作：郎丰利1519制作时间：2023年睿利而行01总体技术架构思路总体技术架构思路–技术架构三原则总体技术架构思路–技术架构三原则总体技术架构思路–技术架构三原则整理制作：郎丰利1519制作时间：2023年睿利而行整理制作：郎丰利1519制作时间：2023年睿利而行整理制作：郎丰利1519制作时间：2023年睿利而行总体技术架构思路–技术架构三原则核心技术架构要支持中台设计（破解烟囱式系统以局为单位建设一个系统）02核心技术架构与核心技术框架要统一01核心技术框架与具体的技术产品进行适配性解耦03总体技术架构思路–技术架构三原则总体技术架构思路–我们要统一什么使用“中台”的设计理念与设计方法怎么做？要破除“烟囱式”应用系统，要做到业务全局共享、数据全局打通为什么这样做？要用全局的架构视角，将所有企业全业务看成一个系统统一架构视角与具体处理方式总体技术架构思路–我们要统一什么

技术架构是系统的技术蓝图，是系统按照不同技术视角从整体到部分的最高层次分解，同时它也包含一些不宜改变的决定。它由多个组件以及他们彼此间的关系组成，并且在一定环境和原则下进行设计和改变。在一个系统里，统一技术架构与技术框架什么是技术架构？什么是技术框架？

按照技术架构的层次分解固化下来的技术层次调用编码，可以在抽象层面上实现技术调用闭环，它是应用编程的基础核心代码，应用系统在框架代码的基础上扩展出业务逻辑，形成应用系统。总体技术架构思路–我们要统一什么技术架构与技术框架的关系技术架构分层结构、层次间调用关系（规范来保证）视图层控制层（技术框架）业务层数据层代码来保证总体技术架构思路–适配地方要具备：技术架构中要求的PAAS层能力，需按照统一标准规范构建云平台的平台服务（Platform-as-a-Service,PAAS）能力，应包括分布式服务、消息队列服务、分布式缓存服务、分布式日志服务、分布式数据访问服务、关系型数据库、非结构化存储服务、离线计算引擎、实时计算引擎、流计算引擎等。能够支持PAAS层服务的IAAS层基础设施。总体技术架构思路–变化全面使用分布式架构云的技术本质：分布式计算。云上的技术：横向扩展，性能线性提升总体技术架构思路–变化从单体架构到微服务架构单体架构的可维护性及复杂度随着系统规模的增加变得越来越难以控制。水平扩展性的成本较高，要整体克隆出一个系统来，通过负载均衡的技术来分担计算压力对压力大的模块，无法分拆出来进行单独扩展过去我们把应用的业务逻辑大量写在数据库中，中间层的压力不大，这种架构还可以应付。如今大量的业务会在中间层完成，中间层的不同的业务模块对硬件的需求并不一样，有的是CPU计算密集型，有的是内存使用密集型，有的是IO密集型，这样在做横向扩展时我们如果克隆出一个应用，那么硬件就要CPU密集、内存够大、IO够强，成本很高。总体技术架构思路–变化从单体架构到微服务架构微服务架构（通过服务的方式解耦、隔离业务变化）微服务架构是一种架构模式，他提倡将单一应用程序划分成一组小的服务，服务之间互相协调，互相配合，为用户提供最终价值。服务与服务之间采用轻量级的通信机制互相沟通，每个服务都能独立的部署到生产环境中。总体技术架构思路–变化从中心化架构到去中心化架构总体技术架构思路–变化从集中式走向分布式应用层单体应用大量使用存储过程中台化微服务化应用可弹性伸缩数据资源层关系型数据库集中存储分布式存储多种存储策略基础资源层小型机为中心X86架构虚拟化可扩展02总体技术架构设计总体技术架构设计–关系IAAS层与PAAS层的关系行业应用要在小资源上运行大应用，怎么办？虚拟化技术只能将一个大的物理资源分割成小的易于部署的虚拟资源，形成资源池，即大化小。我们要依赖分布式技术将这些小资源再次整合成大的、可伸缩的计算能力。总体技术架构设计–逻辑图总体技术架构设计–逻辑图03中台设计一切数据业务化一切业务数据化中台设计–业务中台与数据中台业务中台数据中台业务场景交易处理数据生成用户触点全域数据存储数据萃取数据处理面向场景算法迭代中台设计–什么是中台？中台是由业务中台和数据中台构建起的数据闭环的业务体系，实现以数字化资产的形态提升企业快速服务能力。01step价值主张：为客户提供技术输出服务或人力外包服务。特征：重度订制技术服务商02step价值主张：为客户提供标准化、专业性的软件产品，并提供软件实施服务；特征：产品化，轻订制产品提供商03step价值主张：构建企业软件服务的完整生态，更加注重企业全业务线的软件生态搭建的解决方案；特征：中台生态化，轻订制解决方案提供商中台设计–中台战略是企业服务生态的高级阶段中台设计–中台战略的适用范围多租户SaaS+私有化软件服务提供者多业务信息化系统多个业务系统构成的产品及软件服务生态。提供面向某一领域（CRM/生产制造/…）的全套信息化/互联网解决方案；基于多租户架构的SaaS系统服务软件体系。为客户提供标准产品服务。并提供私属订制实施服务。“软件服务提供者”可以是外部第三方人家服务提供商，也可以是企业内部自有的软件服务开发者；中台设计–中台的价值主张中台战略模型（产品化）独立业务应用/系统（烟囱模型）缺乏产品整体规划，独立系统的业务范围不明确，重复建设所浪费的成本非常高；系统互相独立，业务模型标准不统一，为了业务联接而进行的研发成本过高系统业务范围的盲目放大造成系统功能使用率的下降，同时浪费了大量的运维成本；为了保证业务数据一致性，业务运营需要操作多套系统。极大增加了运营成本。通过有效的研发工具提供规范业务应用的研发标准。实现业务应用系统的快速孵化。抽象领域能力，复用与多个业务场景中，在保证业务数据一致性的同时，有效降低研发成本打通业务联调，构建系统生态中台设计–实施原则统一的业务应用设计标准，研发管理标准，平台和领域能力运营标准。统一标准面对多套业务系统/应用，提供统一的识别标识，以此来保证系统间数据统一和业务协同。唯一标识定义统一的业务能力服务输出方法和业务能力接口。统一服务抽象并定义统一的业务领域模型，并在业务回归（业务应用的开发）中持续的优化升级。统一模型一套标准两个平台三大系统中台设计–产品定义从产品研发到产品运营科学的完整的管理标准链接业务应用提供者与终端客户的业务应用市场客户应用终端系统、租户运营管理中心、租户实例生产系统。中台是面向“业务应用/系统研发团队”的标准化软件生产制造工厂。为业务开发提供标准化的业务构建零部件（抽象并可建议泛化的“领域及能力”），以及软件研发所需的标准化的生产线（基于多租户的OpenAPI服务、微服务治理服务及云计算服务）；中台战略（体系重构）是软件服务提供者的服务模式“改革”，从单一的“企业客户定制开发”或“SaaS产品提供”，升级为支持“服务层标准化产品”+“应用层私属订制”的服务提供模式。中台战略同时会让软件服务生态变得“开放”，允许更多的服务供应商共享业务及数据。中台设计–产品地图基于中台的产品重构中台设计–标准能力开放平台用户细分价值主张关键业务业务应用开发者；领域能力提供商在业务应用开发过程中引用领域能力的关键APIs；在业务系统运行过程中，对租户鉴权，并完成领域能力的调用和监控；建立业务应用系统开发的统一业务标准；构建领域能力的服务生态；中台设计–标准微服务治理中心用户细分价值主张关键业务业务应用开发者提供业务应用开发所需的微服务框架建立业务应用系统开发的统一技术标准；提升业务应用系统开发的效率；中台设计–标准云计算服务中心用户细分价值主张关键业务业务应用开发者提供业务应用开发所需的容器服务、基础