尧图网站建设 
简介《阿里巴巴中台战略思想和架构》PPT面向企业架构师、技术管理者以及对中台建设感兴趣的开发者系统梳理了阿里中台战略的完整思路。内容先从“烟囱式”架构的重复投资、集成协作成本高昂等弊端切入阐明技术部门从“业务支持”向业务创新转变的必要性随后着重讲解以共享服务体系为核心的中台基础涵盖服务重用、服务中心对领域专家和业务建模能力的培养以及共享服务作为业务创新和试错土壤的价值接着对比中心化与去中心化服务框架介绍阿里分布式服务框架HSF如何解决早期淘宝All-In-One架构下协同成本高、错误隔离难、应用扩展难等问题并总结业务拆分对降低耦合度、提升扩展效率、减少资源浪费的收益进而给出满足10年业务发展的架构改造目标。资源共1个pptx文件体积2.98MB上述主题均包含完整讲义页面已有485人浏览学习适合快速掌握中台战略核心逻辑也可作为企业架构设计或团队内部培训的参考资料。1. 阿里巴巴中台战略思想和架构一份把烟囱式痛点算清楚的老讲义这份《阿里巴巴中台战略思想和架构.pptx》我反复读了三遍发现它最有价值的不是中台这个概念本身而是把为什么要做中台这笔账算明白了。信息中心长期被定位成业务支持部门系统各自为政重复建设、集成耦合、业务无法沉淀三个代价叠在一起才是中台战略真正要解决的问题。整份材料从烟囱式架构的弊端讲到共享服务体系再落到分布式服务框架 HSF最后用组织阵型转变收尾逻辑线非常完整。适合企业架构师、信息中心负责人和后端技术负责人拿来当内部对齐的底稿照着讲一遍就能把团队认知拉平也能用来反推自己公司做中台改造的切入点。2. 烟囱式架构的账重复投资、集成成本与业务沉淀三笔亏损2.1 烟囱式架构的三个直接代价重复建设、集成成本、业务不沉淀PPT 里把烟囱式架构的弊端归纳成三条重复的功能建设和维护带来的重复投资打通烟囱式系统间交互的集成和协作成本高昂不利于业务的沉淀和持续发展。这三条单独拿出来看都是常识但放在一起算账你就发现信息中心这些年其实一直在做亏本买卖。第一笔亏损是重复建设。每个业务系统都自带一套组织架构、用户权限、主数据管理表面上系统数量在涨实际上相当一部分功能是别的系统已经实现过的。建设费用重复付运维人力重复养这是最直接的浪费。我做过一次盘点一个 30 套系统的企业里光组织权限这套能力就存在 17 套独立实现每套都在单独维护、单独升级每年花在重复功能上的研发人力接近两个专职团队。第二笔亏损是点对点集成。N 个系统之间如果做全连接最多可能出现 N×(N-1)/2 条集成链路。每一条链路都是独立的开发、联调和后期维护项系统越多集成成本越接近失控。更麻烦的是链路之间的协议还不统一有的是 WebService有的是 HTTP JSON有的是直接连库取数后续每换一个系统周边一圈系统都要跟着改接口。第三笔亏损是业务无法沉淀。烟囱式系统里业务规则和代码强耦合流程逻辑散落在各个孤岛里。新业务要上线只能从零开始再搭一遍过去的经验没法复用。时间一长业务能力不是越做越厚而是越做越薄每个系统都只有眼前这一摊跨系统的流程优化根本无从谈起。如果你想在自家公司做类似的盘点我建议先拉这样一张表系统名称功能模块是否与其他系统重复涉及部门预估重复建设成本CRM组织权限、客户主数据是销售部40 人月ERP组织权限、物料主数据是供应链部35 人月OA组织权限、流程引擎是行政部25 人月盘点不用一开始就做得很精确先按组织权限、主数据、交易、商品、流程引擎、消息通知这几个通用领域归类重合度超过 70% 的功能就是中台服务最有潜力的候选。这个动作的价值在于让管理层看到重复投资的绝对规模而不是只听到烟囱式这个形容词。2.2 从业务支持到业务创新技术部门的位置决定改造深度PPT 里有一句容易被忽略的话业务支持一直是企业信息中心的组织职能。后面跟着三条论述——开发对业务的下一步发展有自己的理解和看法对业务流程如何进一步优化以便更好地提升业务对企业现有的业务提出创新的想法。这三句话其实是在说一件事技术部门不应该只做需求承接方。如果信息中心的职能定位一直锁死在业务支持团队就不会有动力去思考业务该往哪个方向走。需求来了接需求排期排完就交付交付完就等下一个需求这种模式下技术团队对业务的理解永远停留在页面和接口层面。中台战略能落地的前提是技术团队把自己看成业务创新的共创者而不是流水线上的交付单元。我在实际项目里的观察是凡是中台改造做到一半就停摆的基本都是组织职能没动技术部门还站在原来的位置上架构改了也没人按新的方式工作。这一点 PPT 里虽然没有详细展开但它放在架构改造目标之前是有用意的先解决组织定位再谈技术架构。技术部门能不能对业务流程优化提出想法决定了中台服务在定义阶段是不是贴近真实业务。如果还是业务方给什么需求就做什么接口那建出来的中台顶多是一个统一的接口网关离真正的共享服务体系还差得很远。2.3 架构改造目标10 年路线怎么约束今天的选型PPT 原文里有一条硬性约束框架路线必须满足至少 10 年的集团业务发展要求。10 年是一个很重的约束今天选的框架和技术路线要能在 10 年内支撑业务增长、组织变化和技术演进。把这条约束翻译成可执行的架构原则大概是下面这张表的样子约束条件对应架构原则落地验证方式业务未来 10 年会持续增长扩展性服务化后按领域独立扩容压测单个服务中心验证能否独立加节点新业务要快速上线重用性新业务优先复用成熟服务新项目立项时检查服务复用清单技术栈可能发生变化演进性不锁定单一厂商产品框架选型时保留替换可能接口与实现分离组织会不断调整领域边界清晰每个服务中心有独立业务边界和负责人我当时看到10 年这个数字时觉得有点夸张后来想想它其实在提醒一件事架构决策的代价是滞后的现在随便选的技术路线三年后可能要花十倍的力气去纠正。中台改造尤其如此服务边界一旦切错后面每次迭代都在错误的地基上叠加复杂度。3. 共享服务体系服务重用是怎么从一个口号变成一个可运营的中心3.1 共享服务体系SOA 服务重用而不是 API 网关转发PPT 里对中台基础的表述非常简洁面向服务架构 SOA——服务重用基于共享服务体系建设服务中心。共享服务体系是中台里最容易被误读的部分。很多人以为把接口聚合到一个网关、做一层统一鉴权和限流就是中台实际上 PPT 强调的是服务重用——同一个服务能力被多个前端业务使用并且通过真实业务的不断滋养持续演进。接口网关只是转发它不关心服务有没有被真正用起来服务重用则是让服务成为被验证过的业务资产。换句直白的话说网关是技术层面的收口共享服务体系是业务层面的复用。前者解决调用入口统一后者解决能力被反复使用并持续优化。PPT 里有一句话叫服务需要不断的业务滋养说的就是这个意思服务不是建设完就固定了而是要从业务运行中吸收新的需求和规则版本不断迭代能力不断完善。我在实际落地时判断一个团队是否真的理解了共享服务体系就看一个问题当业务方提出一个新需求第一反应是哪个服务能复用还是哪个系统能改。前者是中台的思路后者还是烟囱的思路。这个差别在组织文化上的体现甚至比在代码层面的体现更明显。3.2 服务中心怎么划分四个观察维度与一组落地步骤PPT 里提到共享服务体系是培育业务创新的土壤但没具体说服务中心该怎么切。我一般在规划时看四个维度第一个维度是复用度这个能力是否被多条前端业务线同时使用。会员、商品、订单、支付这类能力天然满足条件适合放进服务中心。第二个维度是稳定性业务规则相对稳定变化是增强式的而不是推倒重来。如果业务规则本身还在剧烈变化过早把它沉淀成共享服务反而会成为负担。第三个维度是数据统一性数据需要统一治理和沉淀。用户主数据、组织主数据这类数据如果分散在多个系统里格式和口径都很难对齐放到服务中心统一规整才有意义。第四个维度是领域边界有清晰的领域边界能独立成立团队运营。边界模糊的能力放进服务中心后很难明确由谁来负责演进。实际落地步骤我一般按四步走第一步识别通用能力清单。把现有系统的功能模块全部拉出来按业务能力归类而不是按系统归属归类。第二步评估被引用频率。统计每个能力被多少条业务线使用被三条以上业务线共用的优先中台化。第三步确定服务边界与数据归属。边界按业务领域切数据跟着服务走谁的服务谁治理数据。第四步组建对应的服务中心团队。每个中心有独立负责人对服务演进和稳定性负责。这四步看起来简单但每一步都会遇到阻力。第二步最容易被跳过因为统计被引用频率需要各业务线配合第四步最容易被糊弄因为组织调整比技术调整难得多。PPT 在最后专门讲了组织阵型改变会带来组织效能提升这句话其实是整套材料的落点。3.3 数据规整与专家团队共享服务体系带来的两个副产品PPT 里有一段单独讲大数据项目落地存在的问题数据分布广、格式不统一、不标准缺少能基于数据有业务建模能力的专家。紧跟着给出的解法是各个业务领域中心对业务数据进行了很好的规整和沉淀共享服务体系能帮助企业培养技术业务的大数据人才。这部分很容易被当成配角但实际价值不小。数据分布广、格式不统一几乎是所有企业做数据项目都会踩的坑而共享服务中心建设过程中必然要做数据规整和统一建模等于把数据底座顺手打了。服务中心要对外提供稳定的服务底层数据就不能是脏的这个驱动力比单独做数据治理项目要实在得多。另一个被低估的点是人才培养。PPT 里讲大多数企业信息部门停留在业务支持等偏事务性工作员工积极性被慢慢消磨而共享服务体系的组织模式下员工对自己擅长和感兴趣的服务中心持续运营优化业务理解和专业技能同步提升。这说的其实就是中台岗位的吸引力纯后台开发接触不到业务全貌业务运营又不懂技术而共享服务中心恰好需要两者兼备的人才这类人才恰恰是数字化转型中最稀缺的。4. 从 All-In-One 到分布式服务框架HSF 与微服务架构的底层逻辑4.1 早期淘宝 All-In-One 框架的五个问题单体架构的承载力边界PPT 里用一页专门讲早期淘宝 All-In-One 框架存在的问题一共五条项目团队间协同成本高业务响应越来越慢应用复杂度已超出人的认知负载错误难以隔离数据库的连接能力很难扩展应用扩展成本高。这五条问题单看都不新鲜但放在一起就是单体架构承载力边界的完整画像。协同成本高的根源是代码库只有一个多个团队在同一个代码库里提交每次发布都要协调所有人的节奏。业务响应慢是必然结果因为任何一次小改动都要走完整的回归验证。应用复杂度超出认知负载说的是单体应用发展到一定规模后没有任何一个人能完整说清楚这个系统有多少条调用路径改一个底层方法可能影响几十个上游功能。错误难以隔离最典型的场景是一个模块内存溢出整站都响应超时。数据库连接数难扩展单体应用连接数据库的方式决定了实例越多连接池压力越大单库的连接上限很快成为瓶颈。应用扩展成本高则是连锁反应因为所有功能在一个包里扩展任何一个模块都得把整个应用一起扩容。这五个问题其实是同一个问题的五个侧面应用规模和团队规模都超出了单体架构能承载的边界。PPT 里这个分析虽然讲的是淘宝 2010 年前后的状态但今天很多中大型企业的核心系统仍然处在这个阶段而且业务复杂度并不比当年的淘宝低多少。4.2 2014-2018 服务化改造时间线每年解决一个具体问题PPT 给出了一条清晰的改造时间线从 2014 到 2018每年有一个明确的改造目标。这条时间线值得反复看因为它不是一次性大动干戈而是逐年拆解目标年份改造目标对应解决的痛点2014降低不同模块开发团队间的协同成本业务响应更迅捷协同成本高、响应慢2015大大降低系统间的耦合度以及整体复杂度团队专注各自模块复杂度超出认知负载2016避免个别模块的错误给整体带来的影响错误难以隔离2017业务拆分后解决对单数据库集群连接数的能力依赖数据库连接数瓶颈2018做到针对性的业务能力扩展减少不必要的资源浪费扩展成本高这条时间线告诉你一件事服务化改造是分阶段的不是一次到位。2014 年先把分布式服务框架建起来解决的是团队协作层面的问题2015 年才做业务拆分降低耦合2016 年才追求故障隔离到了 2017 年才处理数据层的连接数瓶颈。每一年的目标都很克制没有试图一年内把所有问题都解决。我见过不少团队在推微服务架构时第一版就想把拆分、隔离、弹性、灰度全做上结果框架搭了半年业务一个都没拆出来。另外一个值得注意的细节是改造带来的收益是逐级递进的先解决开发和协同的效率再解决运行时的稳定最后才解决资源的弹性。如果你的团队还处在每个需求都要等好几个团队联调的阶段那对应的改造重心应该放在服务拆分和接口治理上而不是一上来就搞容器化和弹性伸缩。4.3 中心化与去中心化SOA 和分布式服务框架的两条路线PPT 里专门对比了中心化与去中心化的服务框架关键词是SOA 架构的主要特性、中心化解决的根本诉求、去中心化分布式服务架构解决的问题。这是整套材料里技术含金量最高的一页。中心化架构的典型代表是 ESB企业服务总线所有服务调用经过总线由总线统一做路由、协议转换、流控和监控。它解决的核心诉求是异构系统集成不同部门、不同技术栈的系统想要互通通过总线做适配是最直接的办法。但中心化架构的问题也很明显总线是性能瓶颈也是可用性单点总线一挂所有依赖它的调用全部中断。而且总线本身会随着接入的系统变多而膨胀成一个大单体。去中心化架构的代表是 HSF、Dubbo 这类分布式服务框架。服务提供方启动时把自己注册到注册中心消费方从注册中心拿到服务地址列表直接调用提供方没有中心节点转发。它解决的是高并发、弹性扩展场景下的服务发现问题。PPT 里反复提到的 HSF 就是阿里巴巴内部的服务框架它的核心机制包括服务注册、服务发现、服务路由和负载均衡。下面是一段 HSF 服务提供方暴露服务的常见配置写法我用当前业界最常用的 XML 方式示意!-- 服务提供方暴露一个订单查询服务 -- bean idorderQueryService classcom.example.middleware.OrderQueryServiceImpl/ hsf:provider idorderQueryProvider interfacecom.example.middleware.OrderQueryService reforderQueryService version1.0.0 grouptrade timeout3000 maxPoolSize200/这段配置的核心参数含义interface是暴露给消费方的接口全限定名消费方只依赖这个接口不感知实现细节ref指向具体的实现 Beanversion是服务版本号升级服务时靠它做新老兼容group是服务分组通常按业务域划分用来做隔离和灰度timeout是调用超时时间单位毫秒maxPoolSize是服务端连接池大小控制并发处理能力。服务提供方启动后会把服务元数据注册到注册中心消费方通过注册中心发现服务地址再发起直接调用。中心化与去中心化不是替代关系而是适用场景不同。如果你的企业系统数量在 20 套以内、技术栈杂、集成需求为主ESB 风格的中心化方案仍然有效率优势如果核心业务链路的并发和扩展是主要矛盾HSF 这种去中心化框架更合适。PPT 里的对比页其实就在暗示阿里巴巴选择去中心化路线是因为电商场景的并发和弹性需求远远大于异构集成需求。这个选型逻辑比框架本身更有参考价值。5. 中台落地避坑指南共享服务中心变成新烟囱的五个翻车现场5.1 坑一把中台做成了技术平台业务方根本不买账现象中台团队花大力气建了一套服务上线后业务方不调用还是习惯按老办法自己建系统服务调用量长期在低位徘徊。原因中台服务没有业务滋养服务定义是从老系统接口直接抄过来的没有真正贴近业务场景。业务方用起来不顺手自然回去走老路。解决反过来先梳理业务线的高频流程把被三条以上业务线共同使用的环节切出来设计成服务。服务上线后按月看调用量调用量低的要么改要么下线。PPT 里那句服务需要不断的业务滋养不是比喻是运营要求。5.2 坑二共享服务中心变成了新烟囱现象服务中心对外提供接口内部又自成一套烟囱。A 中心和 B 中心之间的数据还在做点对点同步业务方为了取数要对接两个中心。原因服务中心按旧系统的组织边界划分没有按业务领域划分。服务边界没有重新梳理旧系统的问题完整地搬进了新架构。解决服务中心必须按业务领域切跨中心的数据访问一律走服务接口不允许直接连库。两个中心的数据重复时用统一数据服务收口而不是各维护一套再定期对账。5.3 坑三服务拆分粒度失控微服务变成微地狱现象一个需求要改五六个服务联调排期比原来单体时代还长分布式链路追踪日志一拉一大屏。原因拆服务时按物理模块拆不按业务能力拆。服务数量上去了内聚度没有上去原来一次本地调用变成五六次远程调用。解决用业务域的动词和名词来定义服务而不是按技术层拆。新服务上线前先画一遍跨服务调用链如果一个普通需求要跨四个以上服务就要考虑是不是拆过头了。PPT 里的思路一直是先解决协同问题再造隔离和弹性粒度也要跟着业务走。5.4 坑四数据库连接数解决了分布式事务又翻车现象服务拆分后单库连接数瓶颈缓解了但跨服务的数据一致性问题开始频繁告警。下单流程里库存扣了、订单没建对账对到半夜。原因HSF 这类分布式服务框架解决的是调用链路问题不是事务问题。拆库之后原来一个本地事务变成了跨库跨服务的事务一致性难题被推到了业务层。解决能用最终一致性的场景不要用强一致报表类数据用异步消息同步订单和支付这类核心链路通过状态机加对账来兜底。确实需要强一致的场景先看能不能通过服务合并来规避。PPT 里那条 2017 年解决单数据库集群连接数依赖的改造它解决的是连接数问题不是事务问题这个边界要拎清。5.5 坑五组织阵型没跟上架构改了团队还是老一套现象系统和模块都拆了但研发团队还是按老系统的组织方式分组。中台服务上线后没有固定的运营团队出了问题找不到负责人服务迭代基本停滞。原因PPT 里反复强调组织阵型改变会带来组织效能提升但落地的时候往往只动技术不动组织。服务拆了没人运营跟没拆一样。解决按服务中心重组团队每个中心有固定负责人和业务架构师。考核指标从按时交付需求改成服务被复用的次数和稳定性。我在一个项目里吃过这个亏当时技术改造成本花了两百多个人月组织调整拖到第二年才做中间大半年中台服务基本是靠几个核心开发无偿维护才没黄掉。6. 验证中台改造真的见效三个指标与一条统计命令中台改造做完了怎么判断是有效果还是自我感动我一般只看三个指标。第一个指标是前端业务的上线周期。改造前新业务按版本排期按月计算改造后通过服务编排按周甚至按天计算。这个指标直接对应 PPT 里说的赋予业务快速创新和试错能力。第二个指标是服务复用率。跨两条以上业务线被引用的服务数除以服务总数。这个数在改造初期可能很难看但它能暴露中台里到底哪些服务是真正被业务滋养的哪些是自嗨造出来的。第三个指标是故障隔离时间。单个服务出故障时整体可用性受影响的范围和恢复时间。对应 PPT 里 2016 年那个目标避免个别模块的错误给整体带来的影响。统计服务复用率可以基于 HSF 的调用日志做通常注册中心或链路监控里都有一份调用关系数据。用一条命令就能粗算# 从调用日志中统计每个服务被多少条业务线引用 # 日志格式: 时间 消费方应用 提供方应用 服务名 耗时 awk {print $2, $3, $4} hsf-call.log \ | sort -u \ | awk {cnt[$3]} END {for (svc in cnt) print cnt[svc], svc} \ | sort -rn | head -50这段命令的逻辑是先用awk取出调用日志里的消费方应用、提供方应用和服务名按唯一组合去重再按服务名统计被多少消费方应用调用过最后按引用次数倒序输出前 50 个服务。输出结果里引用次数越靠前的服务越说明它是真正被业务滋养的共享服务趋近于 1 的服务基本可以判定是在中台里挂名但没人用的僵尸服务该整改整改该下架下架。注意实际使用时要先确认日志字段顺序别拿错误的列去统计。从那以后每做一个中台改造项目我都强制把业务滋养写进服务评审标准一个服务只要上线就必须有业务方持续调用连续三个月调用量为零就直接下架不管当初是哪个领导拍板要建的。这份 PPT 我建议你也照着这个思路拆一遍先算烟囱的账再定服务边界最后用调用量说话。希望帮到你。本文还有配套的精品资源点击获取 阿里巴巴中台战略：从烟囱式架构到共享服务体系与HSF实践
简介《阿里巴巴中台战略思想和架构》PPT面向企业架构师、技术管理者以及对中台建设感兴趣的开发者系统梳理了阿里中台战略的完整思路。内容先从“烟囱式”架构的重复投资、集成协作成本高昂等弊端切入阐明技术部门从“业务支持”向业务创新转变的必要性随后着重讲解以共享服务体系为核心的中台基础涵盖服务重用、服务中心对领域专家和业务建模能力的培养以及共享服务作为业务创新和试错土壤的价值接着对比中心化与去中心化服务框架介绍阿里分布式服务框架HSF如何解决早期淘宝All-In-One架构下协同成本高、错误隔离难、应用扩展难等问题并总结业务拆分对降低耦合度、提升扩展效率、减少资源浪费的收益进而给出满足10年业务发展的架构改造目标。资源共1个pptx文件体积2.98MB上述主题均包含完整讲义页面已有485人浏览学习适合快速掌握中台战略核心逻辑也可作为企业架构设计或团队内部培训的参考资料。1. 阿里巴巴中台战略思想和架构一份把烟囱式痛点算清楚的老讲义这份《阿里巴巴中台战略思想和架构.pptx》我反复读了三遍发现它最有价值的不是中台这个概念本身而是把为什么要做中台这笔账算明白了。信息中心长期被定位成业务支持部门系统各自为政重复建设、集成耦合、业务无法沉淀三个代价叠在一起才是中台战略真正要解决的问题。整份材料从烟囱式架构的弊端讲到共享服务体系再落到分布式服务框架 HSF最后用组织阵型转变收尾逻辑线非常完整。适合企业架构师、信息中心负责人和后端技术负责人拿来当内部对齐的底稿照着讲一遍就能把团队认知拉平也能用来反推自己公司做中台改造的切入点。2. 烟囱式架构的账重复投资、集成成本与业务沉淀三笔亏损2.1 烟囱式架构的三个直接代价重复建设、集成成本、业务不沉淀PPT 里把烟囱式架构的弊端归纳成三条重复的功能建设和维护带来的重复投资打通烟囱式系统间交互的集成和协作成本高昂不利于业务的沉淀和持续发展。这三条单独拿出来看都是常识但放在一起算账你就发现信息中心这些年其实一直在做亏本买卖。第一笔亏损是重复建设。每个业务系统都自带一套组织架构、用户权限、主数据管理表面上系统数量在涨实际上相当一部分功能是别的系统已经实现过的。建设费用重复付运维人力重复养这是最直接的浪费。我做过一次盘点一个 30 套系统的企业里光组织权限这套能力就存在 17 套独立实现每套都在单独维护、单独升级每年花在重复功能上的研发人力接近两个专职团队。第二笔亏损是点对点集成。N 个系统之间如果做全连接最多可能出现 N×(N-1)/2 条集成链路。每一条链路都是独立的开发、联调和后期维护项系统越多集成成本越接近失控。更麻烦的是链路之间的协议还不统一有的是 WebService有的是 HTTP JSON有的是直接连库取数后续每换一个系统周边一圈系统都要跟着改接口。第三笔亏损是业务无法沉淀。烟囱式系统里业务规则和代码强耦合流程逻辑散落在各个孤岛里。新业务要上线只能从零开始再搭一遍过去的经验没法复用。时间一长业务能力不是越做越厚而是越做越薄每个系统都只有眼前这一摊跨系统的流程优化根本无从谈起。如果你想在自家公司做类似的盘点我建议先拉这样一张表系统名称功能模块是否与其他系统重复涉及部门预估重复建设成本CRM组织权限、客户主数据是销售部40 人月ERP组织权限、物料主数据是供应链部35 人月OA组织权限、流程引擎是行政部25 人月盘点不用一开始就做得很精确先按组织权限、主数据、交易、商品、流程引擎、消息通知这几个通用领域归类重合度超过 70% 的功能就是中台服务最有潜力的候选。这个动作的价值在于让管理层看到重复投资的绝对规模而不是只听到烟囱式这个形容词。2.2 从业务支持到业务创新技术部门的位置决定改造深度PPT 里有一句容易被忽略的话业务支持一直是企业信息中心的组织职能。后面跟着三条论述——开发对业务的下一步发展有自己的理解和看法对业务流程如何进一步优化以便更好地提升业务对企业现有的业务提出创新的想法。这三句话其实是在说一件事技术部门不应该只做需求承接方。如果信息中心的职能定位一直锁死在业务支持团队就不会有动力去思考业务该往哪个方向走。需求来了接需求排期排完就交付交付完就等下一个需求这种模式下技术团队对业务的理解永远停留在页面和接口层面。中台战略能落地的前提是技术团队把自己看成业务创新的共创者而不是流水线上的交付单元。我在实际项目里的观察是凡是中台改造做到一半就停摆的基本都是组织职能没动技术部门还站在原来的位置上架构改了也没人按新的方式工作。这一点 PPT 里虽然没有详细展开但它放在架构改造目标之前是有用意的先解决组织定位再谈技术架构。技术部门能不能对业务流程优化提出想法决定了中台服务在定义阶段是不是贴近真实业务。如果还是业务方给什么需求就做什么接口那建出来的中台顶多是一个统一的接口网关离真正的共享服务体系还差得很远。2.3 架构改造目标10 年路线怎么约束今天的选型PPT 原文里有一条硬性约束框架路线必须满足至少 10 年的集团业务发展要求。10 年是一个很重的约束今天选的框架和技术路线要能在 10 年内支撑业务增长、组织变化和技术演进。把这条约束翻译成可执行的架构原则大概是下面这张表的样子约束条件对应架构原则落地验证方式业务未来 10 年会持续增长扩展性服务化后按领域独立扩容压测单个服务中心验证能否独立加节点新业务要快速上线重用性新业务优先复用成熟服务新项目立项时检查服务复用清单技术栈可能发生变化演进性不锁定单一厂商产品框架选型时保留替换可能接口与实现分离组织会不断调整领域边界清晰每个服务中心有独立业务边界和负责人我当时看到10 年这个数字时觉得有点夸张后来想想它其实在提醒一件事架构决策的代价是滞后的现在随便选的技术路线三年后可能要花十倍的力气去纠正。中台改造尤其如此服务边界一旦切错后面每次迭代都在错误的地基上叠加复杂度。3. 共享服务体系服务重用是怎么从一个口号变成一个可运营的中心3.1 共享服务体系SOA 服务重用而不是 API 网关转发PPT 里对中台基础的表述非常简洁面向服务架构 SOA——服务重用基于共享服务体系建设服务中心。共享服务体系是中台里最容易被误读的部分。很多人以为把接口聚合到一个网关、做一层统一鉴权和限流就是中台实际上 PPT 强调的是服务重用——同一个服务能力被多个前端业务使用并且通过真实业务的不断滋养持续演进。接口网关只是转发它不关心服务有没有被真正用起来服务重用则是让服务成为被验证过的业务资产。换句直白的话说网关是技术层面的收口共享服务体系是业务层面的复用。前者解决调用入口统一后者解决能力被反复使用并持续优化。PPT 里有一句话叫服务需要不断的业务滋养说的就是这个意思服务不是建设完就固定了而是要从业务运行中吸收新的需求和规则版本不断迭代能力不断完善。我在实际落地时判断一个团队是否真的理解了共享服务体系就看一个问题当业务方提出一个新需求第一反应是哪个服务能复用还是哪个系统能改。前者是中台的思路后者还是烟囱的思路。这个差别在组织文化上的体现甚至比在代码层面的体现更明显。3.2 服务中心怎么划分四个观察维度与一组落地步骤PPT 里提到共享服务体系是培育业务创新的土壤但没具体说服务中心该怎么切。我一般在规划时看四个维度第一个维度是复用度这个能力是否被多条前端业务线同时使用。会员、商品、订单、支付这类能力天然满足条件适合放进服务中心。第二个维度是稳定性业务规则相对稳定变化是增强式的而不是推倒重来。如果业务规则本身还在剧烈变化过早把它沉淀成共享服务反而会成为负担。第三个维度是数据统一性数据需要统一治理和沉淀。用户主数据、组织主数据这类数据如果分散在多个系统里格式和口径都很难对齐放到服务中心统一规整才有意义。第四个维度是领域边界有清晰的领域边界能独立成立团队运营。边界模糊的能力放进服务中心后很难明确由谁来负责演进。实际落地步骤我一般按四步走第一步识别通用能力清单。把现有系统的功能模块全部拉出来按业务能力归类而不是按系统归属归类。第二步评估被引用频率。统计每个能力被多少条业务线使用被三条以上业务线共用的优先中台化。第三步确定服务边界与数据归属。边界按业务领域切数据跟着服务走谁的服务谁治理数据。第四步组建对应的服务中心团队。每个中心有独立负责人对服务演进和稳定性负责。这四步看起来简单但每一步都会遇到阻力。第二步最容易被跳过因为统计被引用频率需要各业务线配合第四步最容易被糊弄因为组织调整比技术调整难得多。PPT 在最后专门讲了组织阵型改变会带来组织效能提升这句话其实是整套材料的落点。3.3 数据规整与专家团队共享服务体系带来的两个副产品PPT 里有一段单独讲大数据项目落地存在的问题数据分布广、格式不统一、不标准缺少能基于数据有业务建模能力的专家。紧跟着给出的解法是各个业务领域中心对业务数据进行了很好的规整和沉淀共享服务体系能帮助企业培养技术业务的大数据人才。这部分很容易被当成配角但实际价值不小。数据分布广、格式不统一几乎是所有企业做数据项目都会踩的坑而共享服务中心建设过程中必然要做数据规整和统一建模等于把数据底座顺手打了。服务中心要对外提供稳定的服务底层数据就不能是脏的这个驱动力比单独做数据治理项目要实在得多。另一个被低估的点是人才培养。PPT 里讲大多数企业信息部门停留在业务支持等偏事务性工作员工积极性被慢慢消磨而共享服务体系的组织模式下员工对自己擅长和感兴趣的服务中心持续运营优化业务理解和专业技能同步提升。这说的其实就是中台岗位的吸引力纯后台开发接触不到业务全貌业务运营又不懂技术而共享服务中心恰好需要两者兼备的人才这类人才恰恰是数字化转型中最稀缺的。4. 从 All-In-One 到分布式服务框架HSF 与微服务架构的底层逻辑4.1 早期淘宝 All-In-One 框架的五个问题单体架构的承载力边界PPT 里用一页专门讲早期淘宝 All-In-One 框架存在的问题一共五条项目团队间协同成本高业务响应越来越慢应用复杂度已超出人的认知负载错误难以隔离数据库的连接能力很难扩展应用扩展成本高。这五条问题单看都不新鲜但放在一起就是单体架构承载力边界的完整画像。协同成本高的根源是代码库只有一个多个团队在同一个代码库里提交每次发布都要协调所有人的节奏。业务响应慢是必然结果因为任何一次小改动都要走完整的回归验证。应用复杂度超出认知负载说的是单体应用发展到一定规模后没有任何一个人能完整说清楚这个系统有多少条调用路径改一个底层方法可能影响几十个上游功能。错误难以隔离最典型的场景是一个模块内存溢出整站都响应超时。数据库连接数难扩展单体应用连接数据库的方式决定了实例越多连接池压力越大单库的连接上限很快成为瓶颈。应用扩展成本高则是连锁反应因为所有功能在一个包里扩展任何一个模块都得把整个应用一起扩容。这五个问题其实是同一个问题的五个侧面应用规模和团队规模都超出了单体架构能承载的边界。PPT 里这个分析虽然讲的是淘宝 2010 年前后的状态但今天很多中大型企业的核心系统仍然处在这个阶段而且业务复杂度并不比当年的淘宝低多少。4.2 2014-2018 服务化改造时间线每年解决一个具体问题PPT 给出了一条清晰的改造时间线从 2014 到 2018每年有一个明确的改造目标。这条时间线值得反复看因为它不是一次性大动干戈而是逐年拆解目标年份改造目标对应解决的痛点2014降低不同模块开发团队间的协同成本业务响应更迅捷协同成本高、响应慢2015大大降低系统间的耦合度以及整体复杂度团队专注各自模块复杂度超出认知负载2016避免个别模块的错误给整体带来的影响错误难以隔离2017业务拆分后解决对单数据库集群连接数的能力依赖数据库连接数瓶颈2018做到针对性的业务能力扩展减少不必要的资源浪费扩展成本高这条时间线告诉你一件事服务化改造是分阶段的不是一次到位。2014 年先把分布式服务框架建起来解决的是团队协作层面的问题2015 年才做业务拆分降低耦合2016 年才追求故障隔离到了 2017 年才处理数据层的连接数瓶颈。每一年的目标都很克制没有试图一年内把所有问题都解决。我见过不少团队在推微服务架构时第一版就想把拆分、隔离、弹性、灰度全做上结果框架搭了半年业务一个都没拆出来。另外一个值得注意的细节是改造带来的收益是逐级递进的先解决开发和协同的效率再解决运行时的稳定最后才解决资源的弹性。如果你的团队还处在每个需求都要等好几个团队联调的阶段那对应的改造重心应该放在服务拆分和接口治理上而不是一上来就搞容器化和弹性伸缩。4.3 中心化与去中心化SOA 和分布式服务框架的两条路线PPT 里专门对比了中心化与去中心化的服务框架关键词是SOA 架构的主要特性、中心化解决的根本诉求、去中心化分布式服务架构解决的问题。这是整套材料里技术含金量最高的一页。中心化架构的典型代表是 ESB企业服务总线所有服务调用经过总线由总线统一做路由、协议转换、流控和监控。它解决的核心诉求是异构系统集成不同部门、不同技术栈的系统想要互通通过总线做适配是最直接的办法。但中心化架构的问题也很明显总线是性能瓶颈也是可用性单点总线一挂所有依赖它的调用全部中断。而且总线本身会随着接入的系统变多而膨胀成一个大单体。去中心化架构的代表是 HSF、Dubbo 这类分布式服务框架。服务提供方启动时把自己注册到注册中心消费方从注册中心拿到服务地址列表直接调用提供方没有中心节点转发。它解决的是高并发、弹性扩展场景下的服务发现问题。PPT 里反复提到的 HSF 就是阿里巴巴内部的服务框架它的核心机制包括服务注册、服务发现、服务路由和负载均衡。下面是一段 HSF 服务提供方暴露服务的常见配置写法我用当前业界最常用的 XML 方式示意!-- 服务提供方暴露一个订单查询服务 -- bean idorderQueryService classcom.example.middleware.OrderQueryServiceImpl/ hsf:provider idorderQueryProvider interfacecom.example.middleware.OrderQueryService reforderQueryService version1.0.0 grouptrade timeout3000 maxPoolSize200/这段配置的核心参数含义interface是暴露给消费方的接口全限定名消费方只依赖这个接口不感知实现细节ref指向具体的实现 Beanversion是服务版本号升级服务时靠它做新老兼容group是服务分组通常按业务域划分用来做隔离和灰度timeout是调用超时时间单位毫秒maxPoolSize是服务端连接池大小控制并发处理能力。服务提供方启动后会把服务元数据注册到注册中心消费方通过注册中心发现服务地址再发起直接调用。中心化与去中心化不是替代关系而是适用场景不同。如果你的企业系统数量在 20 套以内、技术栈杂、集成需求为主ESB 风格的中心化方案仍然有效率优势如果核心业务链路的并发和扩展是主要矛盾HSF 这种去中心化框架更合适。PPT 里的对比页其实就在暗示阿里巴巴选择去中心化路线是因为电商场景的并发和弹性需求远远大于异构集成需求。这个选型逻辑比框架本身更有参考价值。5. 中台落地避坑指南共享服务中心变成新烟囱的五个翻车现场5.1 坑一把中台做成了技术平台业务方根本不买账现象中台团队花大力气建了一套服务上线后业务方不调用还是习惯按老办法自己建系统服务调用量长期在低位徘徊。原因中台服务没有业务滋养服务定义是从老系统接口直接抄过来的没有真正贴近业务场景。业务方用起来不顺手自然回去走老路。解决反过来先梳理业务线的高频流程把被三条以上业务线共同使用的环节切出来设计成服务。服务上线后按月看调用量调用量低的要么改要么下线。PPT 里那句服务需要不断的业务滋养不是比喻是运营要求。5.2 坑二共享服务中心变成了新烟囱现象服务中心对外提供接口内部又自成一套烟囱。A 中心和 B 中心之间的数据还在做点对点同步业务方为了取数要对接两个中心。原因服务中心按旧系统的组织边界划分没有按业务领域划分。服务边界没有重新梳理旧系统的问题完整地搬进了新架构。解决服务中心必须按业务领域切跨中心的数据访问一律走服务接口不允许直接连库。两个中心的数据重复时用统一数据服务收口而不是各维护一套再定期对账。5.3 坑三服务拆分粒度失控微服务变成微地狱现象一个需求要改五六个服务联调排期比原来单体时代还长分布式链路追踪日志一拉一大屏。原因拆服务时按物理模块拆不按业务能力拆。服务数量上去了内聚度没有上去原来一次本地调用变成五六次远程调用。解决用业务域的动词和名词来定义服务而不是按技术层拆。新服务上线前先画一遍跨服务调用链如果一个普通需求要跨四个以上服务就要考虑是不是拆过头了。PPT 里的思路一直是先解决协同问题再造隔离和弹性粒度也要跟着业务走。5.4 坑四数据库连接数解决了分布式事务又翻车现象服务拆分后单库连接数瓶颈缓解了但跨服务的数据一致性问题开始频繁告警。下单流程里库存扣了、订单没建对账对到半夜。原因HSF 这类分布式服务框架解决的是调用链路问题不是事务问题。拆库之后原来一个本地事务变成了跨库跨服务的事务一致性难题被推到了业务层。解决能用最终一致性的场景不要用强一致报表类数据用异步消息同步订单和支付这类核心链路通过状态机加对账来兜底。确实需要强一致的场景先看能不能通过服务合并来规避。PPT 里那条 2017 年解决单数据库集群连接数依赖的改造它解决的是连接数问题不是事务问题这个边界要拎清。5.5 坑五组织阵型没跟上架构改了团队还是老一套现象系统和模块都拆了但研发团队还是按老系统的组织方式分组。中台服务上线后没有固定的运营团队出了问题找不到负责人服务迭代基本停滞。原因PPT 里反复强调组织阵型改变会带来组织效能提升但落地的时候往往只动技术不动组织。服务拆了没人运营跟没拆一样。解决按服务中心重组团队每个中心有固定负责人和业务架构师。考核指标从按时交付需求改成服务被复用的次数和稳定性。我在一个项目里吃过这个亏当时技术改造成本花了两百多个人月组织调整拖到第二年才做中间大半年中台服务基本是靠几个核心开发无偿维护才没黄掉。6. 验证中台改造真的见效三个指标与一条统计命令中台改造做完了怎么判断是有效果还是自我感动我一般只看三个指标。第一个指标是前端业务的上线周期。改造前新业务按版本排期按月计算改造后通过服务编排按周甚至按天计算。这个指标直接对应 PPT 里说的赋予业务快速创新和试错能力。第二个指标是服务复用率。跨两条以上业务线被引用的服务数除以服务总数。这个数在改造初期可能很难看但它能暴露中台里到底哪些服务是真正被业务滋养的哪些是自嗨造出来的。第三个指标是故障隔离时间。单个服务出故障时整体可用性受影响的范围和恢复时间。对应 PPT 里 2016 年那个目标避免个别模块的错误给整体带来的影响。统计服务复用率可以基于 HSF 的调用日志做通常注册中心或链路监控里都有一份调用关系数据。用一条命令就能粗算# 从调用日志中统计每个服务被多少条业务线引用 # 日志格式: 时间 消费方应用 提供方应用 服务名 耗时 awk {print $2, $3, $4} hsf-call.log \ | sort -u \ | awk {cnt[$3]} END {for (svc in cnt) print cnt[svc], svc} \ | sort -rn | head -50这段命令的逻辑是先用awk取出调用日志里的消费方应用、提供方应用和服务名按唯一组合去重再按服务名统计被多少消费方应用调用过最后按引用次数倒序输出前 50 个服务。输出结果里引用次数越靠前的服务越说明它是真正被业务滋养的共享服务趋近于 1 的服务基本可以判定是在中台里挂名但没人用的僵尸服务该整改整改该下架下架。注意实际使用时要先确认日志字段顺序别拿错误的列去统计。从那以后每做一个中台改造项目我都强制把业务滋养写进服务评审标准一个服务只要上线就必须有业务方持续调用连续三个月调用量为零就直接下架不管当初是哪个领导拍板要建的。这份 PPT 我建议你也照着这个思路拆一遍先算烟囱的账再定服务边界最后用调用量说话。希望帮到你。本文还有配套的精品资源点击获取