中台 、平台架构资料整理

中台 、平台架构资料整理

以下内容摘自于互联网，并非原创
随着互联网进程的推进，新业务模式不断涌现，市场发展对电信传统渠道支撑架构提出了新的要求，诸如O2O线上线下协同、全渠道无缝购物体验、异业合作能力支撑等。 “中台系统”就应运而生了。
作为一种组织架构模式，中台”突出的是规划控制和协调的能力，而“前台”强调的是创新和灵活多变。同样的，引申并运用到电商设计概念中，这是一种快速设计和迭代的方法。“中台”突出整个设计的总体和协调性，而“前端”强调设计的创新和适应性，又或者说差异化。
“大中台”是什么？概括起来就是为电商产品提供快速设计方法和系统性后端服务而诞生的同质化的操作流程，和统一化的产品服务。而为什么会有“大中台”呢？我们总结了电商产品的特性，即操作流程同质性和产品功能趋同性，大家可能还不理解为何为有这样的特性，那么我们来看一下电商平台产品的用户体验地图。
我们把这一整套流程分为“售前”“售中”和“售后”三大块。你会发现绝大部份的在线电商平台所提供的服务都逃不开这三块内容。
我们进一步分析，为了这套提供购物流程的服务，需要一整套的前端模块，而这套模块又大致可以分为三部份，“购物流程”即我们所说的“正向流程”，“售后流程”即我们所说的“逆向流程”，以及服务于用户体验流程和附加服务所需要的“用户中心”。那么为了服务于前端的这些功能模块，我们又需要建立相应的后台模块，这些模块则包含“商品管理”、“订单管理”、“售后管理”、“活动管理”、“优惠信息”、“商家管理”等等，除此之外还需提供线上下的配套服务系统有“仓储物流”和“运营系统”等，这整套的系统，可以服务于绝大部分的电商平台，于是可称之为“大中台”。而作为UED的设计师，可能许多都涉及不到后台系统和线下的服务设计，最主要的设计对象就是“前端模块”。
那么为何需要“大中台”呢？由于一套的“大中台”系统可以同时运用在许多电商平台的设计和服务中，所以“大中台”可以在同时开发多种电商平台的互联网企业里节省设计、开发和运营成本。有了完整统一的后台服务、客服系统、运营系统、仓储物流系统等，就可以将这些整合打包以服务于多个前端系统了。
接下来让我们来看看“小前端”又是什么？“小前端”是基于“大中台”的基础上，为不同特性的电商产品提供差异化的设计服务，总结来说，就是突出产品特性，提升细节体验。在使用统一大中台的多个前端平台中，需要突出产品特性和差异化以及不同的产品定位，就需要设计不同的小前端来细化和提升用户体验及产品感知。
基本来说一个电商产品，在完整的“大中台”基础上，只需根据产品特性，做出相应的模块增减，设计具有特色和适应性的“小前端”，就可以满足绝大多数的业务需求。

技术视角
中台可定义为：中台是一套结合互联网技术和行业特性，将企业核心能力以共享服务中心进行沉淀，形成“大中台、小前台“的组织和业务机制，供企业快速低成本的进行业务创新的企业架构。
中台的目的是“提供企业快速低成本创新的能力”，核心是“构建企业共享服务中心”，过程是构建 “大中台、小前台“组织和业务机制。其中，前台作为一线业务，更敏捷更快速适应市场，中台将整个企业的数字运营能力、产品技术能力，对各业务前台形成强力支撑。

1. 共享中心以共享业务+数据能力为主，比如领域服务层+API接口
2. 共享中心的目的是沉淀传统行业业务和数据能力，并开放出去
3. 共享中心是中台的重要部分，目的是实现前端应用和后台的彻底解耦

没有中台前，企业的痛点体现在：
复杂：系统庞大、逻辑复杂 （学习理解成本高，每人了解系统全貌，最懂的是程序员，需要翻代码才能知道具体逻辑）
重复：系统差异性大、标准不一 （同样的需求在不同系统重复造轮子，对于一个通用功能，没人说清楚是否有，或知道但现有的够不够支持）
沟通成本高：团队多，跨部门的沟通多（无用的拉通对齐会太多，沟通需求和信息获取成本极高）

中台就是为了让企业进行核心能力的沉淀，更给予我们快速创新的机会，具体包括：
1、中台赋予业务快速创新和试错能力
企业可以聚焦核心共享服务的建设，提高服务的重用。
2、打造数字化运营能力
中台有助于业务通过共享核心能力的沉淀，进行数字化运营。通过对中心核心数据的分析，更加精确地对业务进行调整和优化，全方位动态调整资源利用。
3、改变组织阵型带来组织效能提升
中台的变化也是组织阵型的变化。一方面，对于公司，中台侧重的是跨部门跨团队的深入合作。另一方面，对于个人，中台推荐的是类微服务的小而精团队，员工从事多种岗位，对全局和整体有更深入的锻炼。

中心化类似烟囱式架构，一个中心解决整个技术堆栈。平台的目标为高内聚、低耦合、职责边界清晰，是单一团队、部门、系统的效率提升。
中台的目标是提升效能、数据化运营、更好支持业务发展和创新，是多领域、多BU、多系统的负责协同。
中台是平台的自然演进：这种演进带来“去中心化“的组织模式，突出对能力复用、协调控制的能力，以及业务创新的差异化构建能力。

中台是真正为前台而生的平台（可以是技术平台，业务能力甚至是组织机构），它存在的唯一目的就是更好的服务前台规模化创新，进而更好的响应服务引领用户，使企业真正做到自身能力与用户需求的持续对接。

有了“中台”这⼀新的Pace-Layered断层，我们即可以将早已臃肿不堪的前台系统中的稳定通用业务能力“沉降”到中台层，为前台减肥，恢复前台的响应⼒；又可以将后台系统中需要频繁变化或是需要被前台直接使用的业务能力“提取”到中台层，赋予这些业务能力更强的灵活度和更低的变更成本，从而为前台提供更强大的“能力炮火”⽀援。
电商经过十几年的发展，组织已经庞大而复杂，业务不断细化拆分，也导致野蛮发展的系统越来越不可维护，开发和改造效率极低，也有很多新业务不得不重复造轮子，所以中台的目标是为了解决效率问题，同时降低创新成本。
所谓的业务中台就是：通过制定标准和机制，把不确定的业务规则和流程通过工业化和市场化的手段确定下来，以减少人与人之间的沟通成本，同时还能最大程度地提升协作效率。
中台的目标：减少沟通成本，提升协作效率。中台的实现手段：制定标准和规范。原则：集中管控，分布式执行。那么应该如何建设中台，我们先看一下中台的定位。

业务中台需要收敛一些基础的业务服务，如会员、商品、交易、营销和结算等。这些基础的服务会被整个电商业务使用，所以统一管理是很有必要的。
那么业务中台还需要什么？因为中台的目标是要向上层业务提供这些基础的服务，那自然必须能够清楚地描述自己到底有哪些服务、数据和功能，我们可以把它统称为能力。所以还需要能够定义能力（标准和规范）、能力的发现、能力的注册、能力的列表以及能力的评价和更新机制等。
业务中台也不是什么都做，除了有基本的基础服务和服务能力外，还要定义中台的边界。下图描述了业务中台一些基本的工作范围，它需要能够对接能力，同时又服务好能力使用方，而自己并不负责实现具体的业务。

企业的后台系统，在创建之初的目标，并不是主要服务于前台系统创新，而更多的是为了实现后端资源的电子化管理，解决企业管理的效率问题。这类系统要不就是当年花大价钱外购，需要每年支付大量的服务费，并且版本老旧，定制化困难；要不就是花大价钱自建，年久失修，一身的补丁，同样变更困难，也是企业所谓的“遗留系统”的重灾区。

前台：由各类前台系统组成的前端平台。每个前台系统就是一个用户触点，即企业的最终用户直接使用或交互的系统，是企业与最终用户的交点。例如用户直接使用的网站，手机App，微信公众号等都属于前台范畴。
后台：由后台系统组成的后端平台。每个后台系统一般管理了企业的一类核心资源（数据+计算），例如财务系统，产品系统，客户管理系统，仓库物流管理系统等，这类系统构成了企业的后台。基础设施和计算平台作为企业的核心计算资源，也属于后台的一部分。

有了“中台”这⼀新的Pace-Layered断层，我们即可以将早已臃肿不堪的前台系统中的稳定通用业务能力“沉降”到中台层，为前台减肥，恢复前台的响应⼒；又可以将后台系统中需要频繁变化或是需要被前台直接使用的业务能力“提取”到中台层，赋予这些业务能力更强的灵活度和更低的变更成本，从而为前台提供更强大的“能力炮火”⽀援。

所以，企业在平台化的过程中，需要建设自己的中台层（同时包括技术中台，业务中台和组织中台）。

开发效能是构建前中台应用过程中必不可少的重要一环。这方面的实践和能力通过沉淀，结合快速开发框架平台，例如微服务开发平台，就形成了企业的研发中台

业务中台提供重用服务，例如用户中心，订单中心之类的开箱即用可重用能力，为战场提供了强大的后台炮火支援能力，随叫随到，威力强大；
数据中台提供了数据分析能力，帮助我们从数据中学习改进，调整方向，为战场提供了强大及时的雷达监测能力，帮助我们掌控战场；
移动及算法中台提供了战场一线火力支援能力，帮助我们提供更加个性化的服务，增强用户体验，为战场提供了陆军支援能力，随机应变，所向披靡；
技术中台提供了自建系统部分的技术支撑能力，帮助我们解决了基础设施，分布式数据库等底层技术问题，为前台特种兵提供了精良的武器装备；
研发中台提供了自建系统部分的管理和技术实践支撑能力，帮助我们快速搭建项目，管理进度，测试，持续集成，持续交付，是前台特种兵的训练基地及快速送达战场的机动运输部队；
组织中台为我们的项目提供投资管理，风险管理，资源调度等，是战场的指挥部，战争的大脑，指挥前线，调度后方。

前台想不想用，爱不爱用，好不好用，帮了前台多大的忙，从中台获得了多大的好处，愿意掏出多少利润来帮助建设中台，这才是甄别中台建设对错好坏的唯一标准。 对于中台来讲，前台就是用户，以用户为中心，在中台同样适用。

业务中台使得任何一条业务线都具备整个公司的核心能力。
所有业务共享单元的能力共同支撑了阿里巴巴整个业务集团的发展。业务中台能够赋予整个企业快速进行业务创新的能力。

业务中台是水平的，在这个平台上需要建立自己核心的业务中心，比如，在维护、建设前端业务线的时候不能有自己的会员中心，必须把所有的会员纳入到会员中心里，不仅可以快速创新和试触，也可以防止业务做大后会员之间的打通。所以，使用业务中台的一个好处是其数据中心本身就是打通的。

业务中台建设的方式不是一蹴而就的，它是随着企业本身信息化建设持续进展和业务不断创新最终沉淀下来的。有三个最基本的核心要求：开放，所有业务中台实现对内对外的开放，能够极大促进企业业务能力的发展；滋养，传统企业也需要业务创新，只有新的业务不断冒出来试触才能让业务中台做的更好；数据，对数据的应用。在此之上，有两个基本的能力保障：服务，能力是以服务来对外提供的，所以必须确保服务是足够核心的，在定义业务中台的时候会面临个性化诉求，个性化需求是会以特定方式做二次性开发的；稳定，专业、专注带来稳定。

业务场景-客户管理系统-解决方案
客户管理系统一般存在三个问题：客户数据不完备，其原因是大量线下、渠道用户数据未纳入，现有用户中心管理不到30%用户，用户基本信息字段缺失，姓名、电话、住址等，用户订单等业务数据缺失；客户数据不一致，相同用户，姓名/称呼不一致，基本信息登记混乱，订单等业务数据各系统不一致；客户数据缺乏共享，各渠道单独注册用户，数据大量重复、用户体验差，售后、客服的用户信息来源多样化，效率低、用户体验差，不同系统用户数据割裂，无法360度画像，用户分析和营销缺乏精准度。

所以需要：统一用户管理，为线上线下渠道提供统一用户管理，包括统一注册通道、账户管理、基本信息用户清洗去重机制等；统一用户登录，为多渠道提供统一单点登录管理，提升客户体验，支持账号密码、手机、微信、二维码等多种认证和安全管控手段，支持页面H5代理、api oauth等方式接入；数据共享，各个业务系统客户数据打通共享，对应的业务部门协同服务，让客户得到统一的消费体验。

中台架构目标
业务中台采用领域驱动设计（DDD），在其上构建业务能力SAAS，持续不断进行迭代演进。
平台化定位，进行了业务隔离设计，方便一套系统支撑不同玩法的业务类型和便于定制化扩展。
前后端分离，通过服务接入层进行路由适配转发。
天然的分库分表，消息解耦和分布式缓存设计，支持弹性扩容，以支持大数据高并发场景。
减少沟通成本，提升协作效率，制定标准和规范，集中管控，分布式执行。