问题根源可能出在系统共享、联通和融合能力上。在进行应用建设时，有人可能会站在部门或个人利益角度，特别强调和关注应用的局部“可用”，却忽略了企业级业务和流程的整体“好用”。出现了明显的系统边界和系统重复建设问题，难以支持企业级业务能力的快速融合，不能快速响应企业级业务和商业模式创新，对前台一线业务支持和融合不好，难以在前台形成一致的用户体验，最终影响企业业务发展。
1.2 传统企业大数据战略和阿里中台战略的主要差异？- 阿里采用业务和数据中台相结合的双中台建设模式。业务中台目标是把核心服务链路（会员、商品、交易、营销、店铺、资金结算）整体当做一个平台产品来做，为前端业务提供的是业务解决方案，而不是彼此独立的系统。
- 传统企业的很多平台只是将部分通用的公共能力独立为共享平台。这类平台虽然可通过API或以数据服务的形式对外提供共享服务，解决系统重复建设问题，但没有与企业内的其他平台或应用实现从前端到后端的页面、业务流程和数据的全面融合，没有将企业核心业务服务链路作为企业级解决方案来考虑。各平台仍然是分离且独立的，本质上仍然是烟囱式建设模式。
- 项目级的平台虽然解决了公共能力复用能力，但与企业级中台的建设目标还有一定差距。
- 中台源于平台，但它的战略高度高于平台，中台设计时会站在企业高度，更多从业务领域出发进行抽象和标准化设计，形成企业级的整体解决方案，实现企业级业务能力复用。主要体现在：对前台业务的快速响应能力；企业级复用能力；从前台、中台到后台的设计、研发、页面 *** 作、流程、服务和数据的无缝联通、融合能力。最关键的是业务快速响应能力和企业级无缝联通及融合能力。
传统企业的中台建设策略需要从业务中台和数据中台的双中台模式。在中台设计与规划时，要整体考虑企业内前台、中台及后台应用的协同，实现不同渠道应用的前段页面、流程和服务的共享，还有核心业务链路的联通以及前台流程和数据的融合、共享，以支持前台一线业务和商业模式创新。企业中台业务能力建设一般会经历“分”和“合”两个过程。通过将企业可复用的能力沉淀，形成多个不同业务领域职责单一的中台领域模型，然后对不同类型的中台业务能力进行组合和编排，形成企业级业务能力，从而在企业领域模型的“稳”和商业模式与业务流程的“变”中找到最佳平衡。
- “分”的主要目标是通过业务领域边界划分和微服务拆分，建立稳定的、单一职能的领域模型，让业务和应用具有更强的扩展和复用能力。但分不是目的，而是手段，是根据单一职责原则实现业务能力的复用和高内聚。分的过程主要发生在业务中台，在完成业务领域和微服务拆分后，讲点了应用建设的复杂度，使业务和应用具有更强的扩展能力和稳定性。
- “合”包括业务能和和数据融合。业务融合主要作用在前台，实现企业不同业务板块能力的联通、组装和整合，实现企业级业务流程的融合，提供一致的前台用户体验。而数据融合则主要作用在数据中台，实现企业不同业务板块数据的汇集、集成、智能分析和商业模式创新等，为企业前台业务提供统一的智能化数据服务。
- 前台：主要面向客户以及终端销售者，实现营销推广以及交易转换
- 中台：主要面向运营人员，完成运营支撑。
- 后台：主要面向后台管理人员，实现流程审核、内部管理以及后勤支撑，比如采购、人力、财务和OA等系统
在前台设计时，可借鉴微前端的设计思想，通过企业级主应用与微前端应用集成，不及可实现前端页面逻辑的解耦和页面级服务的复用，还可根据企业核心业务链路和业务流程，通过对不同业务板块微前端页面的动态组合和编排，实现企业级前台业务的融合。
3.2 中台传统企业的核心业务大多是基于集中式架构开发的。存在扩展能力弱、d性伸缩能力差问题，无法适应突发高频访问的互联网业务场景。同时，传统企业数据类应用大多通过ETL工具抽取数据以实现数据建模、统计和报表分析功能。这种传统数仓会存在时效性问题，再加上传统数据类应用主要面向企业管理和决策分析，并不是为前台而生的，因此难以快速响应前台一线业务的数据服务要求。
所以，在企业数字化转型时，需要同时解决传统的业务和数据应用建设问题，采用双中台模式同步建设业务中台和数据中台。
3.2.1 业务中台
业务中台的建设可采用DDD方法，通过领域 建模，将可复用的公共能力哦从各个单体中剥离、沉淀并组合。采用微服务架构，建设成为可共享的通用能力中台。
3.2.2 数据中台
数据中台主要完成数据的融合和加工，通过数据智能化，实现智能化的业务和流程创新；通过萃取数据业务价值，提供数据服务，最终实现数字化运营。
数据中台目标如下：
- 完成企业全域数据的采集和存储，实现不同业务类别中台数据的集中管理
- 按照标准的数据规范或数据模型，基于不同主题域或场景对数据进行加工和处理，形成面向不同主题和场景的数据应用，eg：客户视图、代理人视图、渠道视图、机构试图等不同数据服务体系
数据中台建设步骤：
- 实现各中台业务数据的汇集，解决数据孤岛和初级数据共享问题
- 实现企业级实时或非实时全维度数据的深度融合、加工和共享
- 萃取数据价值，支持业务创新，加速从数据转换为业务价值的过程
在设计流程审核和管理类功能时，可考虑按照角色或岗位进行功能聚合，将一些复杂的管理需求从通用的核心业务链路中剥离，通过特定程序入口嵌入前台App或应用中，专门供后台管理人员使用。而对于中台与后台数据交互则可采用事件驱动的异步化的数据最终一致性模式实现数据复制，减轻中台业务压力。
第一部分 认识中台——企业中台能力框架 一、中台能力总体框架中台建设过程从根本上讲是企业自身综合能力持续优化和提升的过程，最终目标是实现企业级业务能力复用和不同业务板块能力的联通和融合。企业级的综合能力，包括：
- 业务能力：体现为对中台领域模型的构建能力，对领域模型的持续演进能力，企业级业务能力的复用、融合和产品化运营能力，以及快速响应市场的商业模式创新能力。
- 数据能力：体现为为企业级数据融合能力、数据服务能力以及对商业模式创新和企业数字化运营的支撑能力。
- 技术能力：体现为对设备、网络等基础资源的自动化运维和管理能力，对微服务等分布式技术架构体系化的设计、开发和架构演进能力。
- 组织能力：体现为一体化的研发运营能力和敏捷的中台产品化运营能力，还体现为快速建设自适应的组织架构和中台建设方法体系等方面的能力。
业务中台一般是指支持企业线上核心业务的中台。业务中台承载了企业核心关键业务，是企业的核心业务能力，也是企业数字化转型的重点。
- 建设目标：将可复用的业务能力沉淀到业务中台，实现企业级业务能力复用和各业务模块之间的联通和协同，确保关键业务链路的稳定高效，提升业务创新效能。
- 业主要目标：实现企业级业务能力的复用，所以业务中台建设需优先解决业务能力重复建设和复用的问题。通过重构业务模型，将分散在不同渠道和业务场景重复建设的业务能力，沉淀到企业级中台业务模型，面向企业所有业务场景和领域，实现能力复用和流程融合。
业务中台实现内容：
- 在技术上实现中台的系统落地可采用微服务架构
- 业务模型上，中台领域建模可采用领域驱动设计方法，通过划分业务限界上下文边界，构建中台领域模型，根据领域模型完成微服务拆分和设计。
- 业务中台建设完成后，前台应用可联通和组装各个不同中台业务模块，既提供企业级一体化业务能力支撑，又可提供灵活的场景化销售能力支撑。
数据中台除了拥有传统数据平台的统计分析和决策支持功能外，会更多聚焦于为前台一线交易类业务提供智能化的数据服务，支持企业流程智能化、运营智能化和商业模式创新，实现“业务数据化”和“数据业务化”。数据中台建设模式变化：
- 数据应用技术发展迅猛。近几年涌现出了大量新的数据应用技术。如NoSql、NewSql和分布式数据库等，以及数据采集、数据存储、数据建模和数据挖掘等大数据相关技术。这些技术解决业务问题的能力越来越强，但同时也增加了技术实现的复杂度。
- 数据架构更加灵活。在从单体向微服务架构转型后，企业业务和数据形态也发生了很大的变化，数据架构已经从集中式架构向分布式架构转变。
- 数据来源更加多样化，数据格式更加多样化。随着车联网、物联网、LBS和社交媒体等数据的引入，数据来源已从单一的业务数据向复杂的多源数据转变，数据格式也已经从结构化为主向非结构化多样模式混合的方向转变。
- 数据智能化应用将会越来越广泛。在数字新基建的大背景下，未来企业将汇聚多种模式下的数据，借助深度学习和人工智能等智能技术，优化业务流程，实现业务流程的智能化，通过用户行为分析提升用户体验，实现精准营销、反欺诈和风险管控，实现数字化和智能化的产品运营以及AIOps等，提升企业数据智能化水平。
数据中台工作包括：
- 建立统一的企业级数据标准指标体系，解决数据来源多元化和标准不同意的问题。企业在统一的数据标准下，规范有序的完成数据采集、数据建模、数据分析、数据集成、数据应用和数据资产管理。
- 建立与企业能力相适应的数据研发、分析、应用和资产管理技术体系。结合企业自身技术能力和数据应用场景，选择合适的技术体系构建数据中台。
- 构建支持前台一线业务的数据中台。在业务中台建设的同时，需要同步启动数据中台建设，整合业务中台数据，消除不同业务板块核心业务链条之间的数据孤岛，对外提供统一的一致的数据服务。用“业务+数据”双中台模式，支持业务、数据和流程的融合。
业务中台落地时需要很多的技术组件支撑，这些不同技术领域的技术组件就组成了技术中台。技术中台有以下几类关键技术领域的组件：
4.1 API网管微服务架构一般采用前后端分离设计，前段页面逻辑和后端微服务业务逻辑独立开发、独立部署，通过网管实现前后端集成。前台应用接入中台微服务的技术组件一般是API网关。API网关主要包括：鉴权、降级限流、流量分析、负载均衡、服务路由和访问日志等功能。API网关可帮助用户，方便地管理微服务API接口，实现安全的前后端分离，实现高效的系统集成和精准的服务监控。
4.2 开发框架开发框架主要包括前段开发框架和后端微服务开发框架。基于前、后端开发框架，分别完成前段页面逻辑和后端业务逻辑的开发。前段开发框架主要是面型PC端或移动端应用，用于构建系统表示层，规范前后端交互，降低前段开发成本。
微服务开发框架用于构建企业级微服务应用。一般具备自动化配置、快速开发、方便调试及部署等特性，提供微服务注册、发现、通信、容错和监控等服务治理基础类库，帮助开发人员快速构建产品级的微服务应用。
4.3 微服务治理微服务治理是在微服务的运行过程中，针对微服务的运行状态采取的动态治理策略，如注册服务、发现、限流、熔断和降级等，以保障微服务能持续稳定运行。微服务治理主要应用于微服务的运行中的状态监控、微服务运行异常时的治理策略配置等场景，保障微服务在常见异常场景下的自恢复能力。
微服务治理技术组件一般包括服务注册、服务发现、服务通信、配置中心、服务熔断、容错和微服务监控等组件。常见的微服务治理有Dobbo、Spring Cloud 和Service Mesh等技术体系。
4.4 分布式数据库分布式数据库一般都是有较强的数据线性扩展能力，它们大多采用数据多副本机制实现数据库高可用，具有可扩展和低成本等技术优势。分布式数据库一般包括以下三类：
- 交易型分布式数据库：用于解决交易性业务的数据库计算能力，它支持数据分库、分片、数据多副本，具有高可用的特性，提供统一的运维界面，具备高性能的交易性业务数据处理能力。主要应用于具有跨区域部署和高可用需求，需支持高并发和高频访问的核心交易类业务场景。
- 分析型分布式数据库：通过横向扩展和并行计算能力，提升数据整体计算能力和吞吐量，支持海量数据分析。主要应用于大规模结构化数据的统计分析、高性能交互式分析等场景，如数据仓库、数据集市等。
- 交易分析混合型分布式数据库：通过资源隔离、分时和数据多副本等技术手段，基于不同的数据存储、
- 访问性能和容量等需求，使用不同的存储介质和分布式计算引擎，同时满足业务交易和分析需求。主要应用于数据规模大和访问并发量大，需要解决交易型数据同步到分析型数据库时成本高的问题，需要解决数据入库统一的问题，需要支持高可用和高扩展性等数据处理业务场景。
为了提高应用性能和业务承载能力，降低微服务的耦合度，实现分布式架构下的分布式业务等需求，技术中台还有很多数据处理相关的基础技术组件，包括如下：
- 分布式缓存：将高频热点数据集分布于多个内存集群节点，以复制、分发、分区 和失效相结合的方式进行维护，解决高并发热点数据访问性能问题，降低后台数据库访问压力，提升系统吞吐能力。典型的开源分布式缓存技术组件有Redis
- 搜索引擎：主要解决大数据量的快速搜获和分析等需求。将业务、日志类等不同类型的数据，加载到搜索引擎，提供可扩展和近实时的搜索能力。
- 数据复制：主要解决数据同步需求，实现同构、以后数据库间以及跨数据中心的数据复制，满足数据多级存储、交换和整合需求。主要应用于基于表或库的业务数据迁移、业务数据向数据仓库复制等数据迁移场景。数据复制技术组件大多采用数据库日志捕获和解析技术，在技术选型时需要考虑数据复制技术与源端数据库的适配能力。
- 消息中间件：主要适用于数据最终一致性的业务场景，它采用异步化的设计，实现数据同步转异步 *** 作，支持海量异步数据调用，并通过削峰填谷设计提高业务吞吐量和承载能力。它被广泛用于微服务之间的数据异步传输、大数据日志采集和流计算等场景。另外，在领域驱动设计的领域事件驱动模型中，晓晓中间件是实现领域事件数据最终一致性的非常关键的技术组件，可实现微服务之间的解耦、满足“高内聚、松耦合”设计原则。典型的开源消息中间件有Kafka等。
- 分布式事务：主要解决分布式架构下事务一致性问题。单体应用被拆分成微服务后，原来单体应用大量的内部调用会变成跨微服务访问，业务调用链路汇总任意一个节点出现问题，都坤鞥造成数据不一致。分布式事务是基于分布式事务模型，保证跨数据库或跨微服务场景下的数据一致性。分布式事务孙然可实时保证数据一致性，但过多分布式事务设计会导致系统性能下降。因此微服务设计时应优先采用基于消息中间件的最终数据一致性机制，尽量避免使用分布式事务。
微服务是一种去中心化的架构，去中心化的代价就是运维团队需要由很强的监控和自动化运维能力。企业一方面应尽可能提高自动化研发和运营能力，即加快软件产品交付速度，提高系统稳定性和业务连续性，降低企业的运营成本；另一方面，也需要加强监控告警、限流降级、性能分析诊断等能力，建立精准定位问题、快速分析和解决问题的能力。研发运营的能力主要体现在以下两方面。
5.1 研发运营一体化研发运营一体化是通过组织协同、流程优化和工具平台三者结合，基于整个研发运营团队进行组织协作优化，将软件需求、开发、测试、部署、运维和运营相关流程统一起来，实现项目管理、开发测试、持续交付和应用运营的无缝集成，快速交付高质量的软件和服务。通过将传统的瀑布开发模式优化为敏捷开发模式、实现研发运营团队融合和更快速的产品迭代和软件交付。借助研发运营工具链平台，实现从项目管理、开发管理、测试管理、持续交付和运维管理等全流程自动化管理。
5.2 全链路监控基于应用日志、服务链路和基础资源等多维度监控数据的关联分析，可精确定位和快速解决问题，也可进行事前预测分析，辅助运维人员进行运维决策。
- 应用日志监控通过日志采集、集中存储、实时检索、统计分析等，利用计算引擎对日志数做进一步处理，帮助解决快速定位问题。
- 服务链路调用监控用于跨服务之间的调用链路监控，通过捕获调用链路上每次服务调用的性能指标，分析应用的整体和局部性能，达到快速定位到性能瓶颈点，缩短问题排查时间的目的。
- 基础资源监控室以服务器、网络设备等基础层资源为中心的监控方式，可以建立基础层运维的专业技术体系，提高运维效率，保障设施地高可用，为系统扩容、规划等提供权威的数据支持。
云平台是企业中台实施和落地的核心基础平台，它提供企业业务中台的基础环境，是研发和运营的基础平台。云平台具有自动化的运营能力、全方位的安全管理能力、智能化的全链路监控能力，可满足基地资源和应用的d性伸缩、软件的敏捷交付和自动化运维等要求。
云平台一般会有云服务、云运营和云运维三个基本管理管理。最关键的能力是云服务化能力，包括Iaas层基础资源和Pass层技术组件两类资源的云服务化：
- Iaas层基础资源云服务化是将计算、存储、网络等Iaas层基础资源完成云服务化，实现基础资源的统一管理、快速扩容、统一调度和自动分配。
- Paas层技术组件云服务化是基于K8S、容器等云原生技术，将数据库、微服务等Paas层技术组件完成云服务化。提供d性甚多、高可用的分布式业务处理和计算能力，支持应用和数据库的d性扩展、快速部署和稳定运行。
云运营管理提供租户管理、服务目录管理、流程管理和计量计费等运营所需的云平台日常管理能力。云运维管理提供云平台日常运维所需的各种能力，包括服务水平管理、容量管理、权限管理、日志管理、监控告警和报表分析等。
七、能力聚合在完成中台领域建模和微服务建设后，可复用的业务能力就沉淀到了业务中台。业务中台汇聚了企业大部分的核心业务能力，成为了企业的富能力层。基于业务职责单一原则，业务中台往往会更专注于本领域的业务能力，而不关心企业级前台应用到底如何进行企业级流程组合和编排。
在前台应用和业务中台之间增加一个能力聚合层。通过该层实现跨业务中台的服务组合、编排、能力聚合、服务发布和路由等功能。这些聚合了不同业务中台能力的聚合层服务是一种粗粒度的服务，可作为企业级的整体解决方案，根据不同前台应用的功能和流程要求对多个中台的能力进行灵活的组合和编排，为不同渠道前台应用提供可复用的能力服务。
八、组织架构及中台建设方法 8.1 组织架构组织架构建设涉及企业内不同组织的协同和融合。按照中台产品化的建设思想，技术和业务需要深度融合，形成组织化的中台研发和运营团队。企业要结合自身具体情况，因地制宜的优化组织架构，建立与中台架构能力相匹配的组织架构，提升企业整体效能，更好地支持业务发展和商业模式创新。
8.2 中台建设方法- IT建设方法：主要有微服务设计、敏捷开发、DevOps等方法体系以及相应的技术标准和技术规范等。
- 业务设计方法：有领域驱动设计方法，可知道完成中台领域建模，构建边界清晰的中台领域模型和微服务。
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）