精华内容
下载资源
问答
  • 技术中台建设方法和关键设计

    千次阅读 2020-10-29 08:31:47
    转载本文需注明出处:微信公众号EAWorld,违者必究。作为企业数字化中台建设支撑的技术中台,其前台是企业应用,后台是企业基础设施(网络、存储、计算等资源),可为企业数字化中台建设提供标...

    转载本文需注明出处:微信公众号EAWorld,违者必究。

    作为企业数字化中台建设支撑的技术中台,其前台是企业应用,后台是企业基础设施(网络、存储、计算等资源),可为企业数字化中台建设提供标准化、端到端、柔性(可变化)的软件生产能力,从而提升企业IT系统建设的效率与可用性。本文节选《金融企业数字化中台》部分内容,重点介绍如何建设技术中台。

    技术中台建设的范畴

    汽车制造的全生命周期对应到软件系统:

    • 部件包括几种类型:业务组件、集成组件、技术组件和基础设施组件,这些是软件系统运行的基本部分,其中业务组件主要由业务中台、数据中台提供,基础设施一旦确定变化不大,属于技术中台的后台,技术中台主要关注集成组件、技术组件。

    • 汽车的结构对应到软件系统就是软件的技术架构,即软件系统通过何种方式将部件组合起来运行,相同的部件可以通过不同方式的组合,产生不同的运行方式,技术架构可以分为企业集成架构和应用技术架构两种类型,前者是企业中各应用间互联互通的模式,后者是各独立应用的运行模式,不同业务特征的应用可以有不同的运行模式;

    • 流程对应软件的全生命周期过程,同样可以分为产品设计、软件开发、软件维护几个阶段,形成几个软件工程的“流水线”;

    • 最后,软件生产也需要很多工具,例如开发工具、监控工具、需求工具等等。

    01 应用集成架构:整合企业应用能力

     

    应用集成架构:整合企业应用能力

    所谓集成就是要做整合,从业务使用视角和实施运维的视角看,相关集成组件一般有页面集成、流程集成、服务集成、数据集成和一些其他公共的集成所需组件,例如统一身份认证、统一应用门户框架、统一任务中心、统一组织机构用户、统一流程集成、服务集成、批量文件传输、作业调度等等。

    统一身份认证

    身份认证或身份验证(Authentication)就是对应用程序的“访问者”身份进行验证识别。访问者分两类,一类是需要“用户”登录的客户端;另外一类是“API客户端”,即设备或者应用程序。 

    认证过程中,最常见的身份标识就是账号和密码。实际情况中不同渠道的用户登录方式不同,需要支持各种不同账号登录。企业内部系统常以员工账号、密码登录为主,比较统一;而对客类业务账号类型就五花八门了,如:客户账号、手机号、邮箱、身份证号、银行卡号、法人机构号等等。因此对于不同登录方式的支持,用户与账号的关系应为1:N,即从概念模型上支持一个用户从不同渠道使用不同的账号登录。 

    统一组织机构

    组织机构用户数据是企业运营的基础数据,IT系统中的业务运行离不开组织机构数据。金融企业的IT建设规模大,动辄数以百计的业务系统,如果组织机构数据放任由业务系统各自管理维护,会造成数据标准不统一,系统集成统计等工作无法进行,大量数据的映射转换工作将让人望而却步,久而久之就出现了一个个孤岛应用。 

    对于组织数据标准化,首先需要定义组织机构、岗位、角色、用户等组织机构实体的唯一编码和名称,编码格式要有章可循,并制定好编码规范和管理规则,进而可以精确到数据库字段的名称、类型和长度一致,实现数据标准统一。

     

    有了标准化的组织机构数据,并不意味着一成不变。随着企业发展壮大、业务运营的变化,组织机构也会进行调整以适应新的企业运营模式。结合大型金融企业的一些特点,组织机构数据要具备柔性(可变性)的特点。常见的组织机构的柔性如下:

    • 兼容组织机构数据的多样性,如:支持“多法人”模式。

    • 在主体框架范围内,支持不同业务维度下组织数据的可变性,如:“多维度”模式。

    • 组织机构数据集成方式的多样性,如:支持远程接口调用、数据同步共享等集成方式。

    统一应用门户

    企业门户是企业现有应用与新应用的集成节点,使用户能够与人员、内容、应用和流程进行个性化的、安全的、单点式的互动交流。它也是一个集成的、可配置的、个性化定制的工作环境,可以随时随地提供给员工、客户和合作伙伴使用,是企业实现高效管理的重要工具和手段。 

    不论是对客或是对内或是面向不同终端技术类型的门户,通常都具备如下特点:

    • 统一应用入口:

    (1)与授权服务器集成,支持SSO单点登录 

    (2)建设应用商店,支撑规范化的应用管理 

    • 统一信息出口:

    (1)建设内容管理服务,支撑企业信息、知识的通用管理发布 

    (2)“内容管理系统”与“业务应用系统”的连接与集成 

    • 统一流程协作。 

    统一任务中心

    任务中心简单来讲就是整个企业业务人员的待办任务数据池。任务中心可以接收来自流程平台或其他应用系统推送过来的任务、通知、流程等任务数据。业务人员访问业务门户的任务中心应用后,对自己当前的任务可以一目了然,这样既避免了业务人员处理不同业务的时候在不同的业务系统之间的菜单切换,也方便了业务人员对不同业务系统数据之间的比对和分析,使得业务人员将更多的精力专注于业务,进而提升工作效率,节约业务成本。 

    建设统一的集中式任务中心,需要从任务数据的生命周期角度全面考虑,即:任务收集、任务查询、任务结束等几个阶段对任务数据和状态的管理,同时还需要对于任务中心的集中管理、权限进行考量:

    1. 建立标准化数据模型,集成企业任务数据,被动接收外部收集的数据(推荐)。

    2. 对于流程、任务、通知数据的管理,都应该根据其生命周期进行合理的规划。

    ESB和网关之争

    在已有业务系统之间打通服务仍是ESB的核心任务。面对新一代数字化转型中的业务的需求,需要能够围绕一个简单、灵活的标准协议对所有新应用进行连接,相对而言Web Service协议略显沉重,ESB由于其集中式枢纽的地位,快速响应变更对于它来说也不是很合适。 

    在数字化转型时代,在金融企业中 ESB 与API Gateway是共存的,都是IT系统之间的服务集成平台。ESB作为系统之间的服务集成的枢纽,网关则在微服务架构体系的业务领域内部进行系统之间集成通信。不论是ESB还是网关,作为服务集成平台的建设来说,重点应该关注的内容包含:身份验证、权限管控、服务路由能力增强等方面。复杂的服务组装、数据、协议转换工作通常需要编码开发,灵活度低,容易产生故障,不建议在服务集成平台中实施,这类工作建议交给负责交易流应用实施的平台负责。 

    企业级公共文件传输平台

    统一的文件传输解决方案具有集中管理、自动化、实时触发、无人值守等特性,更适合金融企业的实际需求,可以助力企业降低成本,加速业务流转效率。文件传输平台定位为可以面向分布式应用的文件传输平台,应该具备良好的可扩展性、处理性能,且易于管理和维护。要能够抽象各种传输场景和模式,提供多样化的策略配置手段,以达成实现不同节点间的文件可靠、安全、高效传输的目标。

     

    作为企业级的统一文件传输平台,需要支持多种传输的场景,在高效性、高可靠性、安全性、可管控性、平台自身运维能力等方面着重考虑:

    1)支持传输场景的多样性与高效率 

    2)支持传输过程的可靠性 

    3)保障传输过程和平台自身的安全性 

    4)提供集中的管控和审计能力 

    5)平台自身易运维 

    作业调度

    作业调度平台能够为系统的集成和运维提供以下价值:

    • 解放人力,提高工作效率

    • 及时告警,减少损失。

    • 多应用分权管理,保护核心功能和资源。

    • 集中式的全面的作业运行状况分析、预警和系统状态监控。

    作业调度平台建设的关键要素

    1)架构层面采用集中管控和分布运行模式 

    2)作业调度平台的柔性 

    3)高可靠性 

    4)管理监控运维能力 

    02 DevOps:建立数字化的软件生产线

     

    软件生产过程中的十四大浪费

    技术中台设计原则中提到了精益运营理论TOC,落地以DevOps为核心的数字化的软件生产线时也是利用TOC方法论来审视软件生产的全流程,查找其中的瓶颈、制约因素和浪费,然后考虑和践行解决方式,通过度量来考察成果。先来看一下普遍存在的浪费现象。 

    金融企业科技部门的主要流程分类

    大中型项目全生命周期建设和投产流程,通常用于大型项目群的管理过程,以及新增系统的建设管理过程。 

    小型项目全生命周期建设和投产流程,通常用于已有系统的优化、依据业务或技术迭代进行变更管理的过程。

     

    紧急上线流程,通常用于基于SLA保障的紧急处置过程管理。 

    数字化的软件生产全流程融合

    基于DevOps的数字化要与软件生产线全流程相融合,不只是需要软件生产的全流程第一级的流程环节,还需要第二级,甚至第三级的子流程(或流程活动环节)。 

    我们建议进行如下梳理工作:

    • 每个流程活动对应的输入,明确其必选项和可选项,明确其必选项的检查标准(是否可将其结构化,是否可通过程序自动检查其完成程度)。

    • 每个流程活动对应的输出,明确其必选项和可选项,明确其必选项的检查标准(是否可将其结构化,是否可通过程序自动检查其完成程度)。

    • 每个流程活动对应的角色,通过RACI(R:流程由谁发起,A:由谁负责审批,C:如有问题咨询谁,I:流程完成后通知谁)的模型进行表述,从而明确此流程活动的分工操作界面。

    • 要完成此活动需要使用的工具,并且结合其输入、输出,能否将其加工生产的过程自动化。

    我们在分析完每个二、三级子流程(活动)之后,可明确各串联流程活动之间的交付物(此输出为彼输入),以及交付物的质量标准(必选项是哪些,必选项要完成到什么程度才能流入到下一流程活动环节),每个活动的分工梳理清晰之后,才能打通各活动对应的工具形成自动化的工具链,使工件自动化流转。 

    打造数字生产线需要做到的五个统一

    通过以上的讲述,希望大家能够理解,软件生产过程中的精益运营没有那么的“阳春白雪”,更多做的是“下里巴人”的事情。在工业生产中,精益改进体现在流水线工人是通过按钮、还是通过扫描枪、或是通过拉绳通知下游工序环节。如果用了按钮,按钮是放在流水线上(会不会引起误操作),还是放在旁边的柱子上(要不要工人起身)。在软件生产中,其实也是一样的道理,开发人员的代码是每日提交还是单个功能开发完后提交,后续触发的代码评审是每天都审核代码,还是按功能点审核。以上种种都是要在实践中摸索和实践才能找到最适合的点,并且每个组织又因为自身的情况,解决方式又不尽相同。 

    度量与引领性指标必不可少

     

    基于金融行业的特点,提供一些度量视图的建议,从而使我们通过度量,在了解如何建设数字化的软件生产线基础上,能够持续优化我们的生产线。 

    1. 项目群视角:项目群是金融科技管理过程中一个很具特色的项目协同管理方式。在金融企业中,通常单一业务需求或合并后的业务需求会触发多个系统的配合改造来满足,这就出现了一个主项目、多个配合项目协同开发、协同投产的情况。

    2. 部门视角:部门视角则是由科技管理团队/部门划分来决定,并为部门管理来提供决策支撑。在金融企业中,通常按核心类、渠道类、管理类、信贷类进行部门团队的划分。建议将一些引领性指标引入到部门管理之中,并按日/周提供报表、排名、风险等,帮助部门管理者提供决策依据。

    3. 单一系统视角:对于单一系统,依据系统的重要程度和团队大小的差异,开发模式通常分为多月度版本(多特性)并行(如:核心和信贷等系统)和单月度版本串行的模式,也可能根据建设周期的不同在两者之间进行切换。

    以DevOps为基础的数字化生产线

    打造敏捷转型的五横四纵体系,支撑最大化的业务产出和软件价值的快速交付:

    • 横向端到端的工具链打通、五大环境标准化与资源流转、数字化软件生产线与科技管理各级流程融合、产物及质量门禁标准形成、引领指标形成及精益持续改进,部门间的组织融合

    • 纵向需求、开发、测试、运营的敏捷化转型,规则、标准、规范的设定,系统间复杂集成架构的构建与支撑

    DevOps的本质,是在软件生产过程中是落实精益运营思想,杜绝浪费,建立数字化生产线。 

    金融行业在引入DevOps之前,需要先考虑以下五点建议:

    1. 小步快跑好过一蹴而就

    2. 没有“银弹”

    3. 数字化生产线的建设不能只依赖于工具层面

    4. 精益运营思想

    5. 逐步形成精细化管理

    03 微服务平台:支撑企业应用系统建设

    当前应用技术架构微服务化出现的问题与解决原则

     

    从管理角度看包括:

    1)过去的架构和微服务架构的关系。

    2)基于开源的技术众多,选型复杂、困难,并且随着开源版本的升级,企业自行维护存在困难。

    3)研发团队如何组织?

    从技术角度看包括:

    1)数据一致性问题。

    2)服务调用链较长,性能下降。

    3)系统复杂度大幅度提高,因为微服务将系统内的复杂度转移为系统间的复杂度了。

    4)微服务应用测试很复杂。

    5)没有配套工具之配套,无法快速交付。

    需要我们掌握分布与聚合的原则,将面向的问题域分门别类建立起来,为各种技术实现找到明确的定位。分布与聚合这个矛盾的对立统一,我们希望达到:

    • 服务分布、流程统一,即服务是分布式部署的,但是在业务逻辑上能够统一起来;

    • 数据是分布,但是对外呈现的信息是聚合的,事务是完整的;

    • 各分布式模块的感觉(末梢神经)是分布的,但系统的知觉(大脑)是统一的 

    服务分布,流程聚合:服务调用模式

     

    服务调用分为“服务提供者”和“服务消费者”两个角色,“服务提供者”将自己的服务地址等信息登记到“服务注册中心”中,调用者(“服务消费者”)从“服务注册中心”查询到提供者的信息,根据这些信息调用服务。 

    服务调用有两种模式,客户端模式和代理模式:

    • 在客户端模式下,“服务消费者”在向“服务注册中心”查询到自己需要调用的“服务提供者”地址之后,“服务消费者”就会自己根据地址去直接访问微服务,此时需要客户端自己实现负载均衡逻辑。

    • 在代理模式下,“服务消费者”通过 API Gateway 组件与微服务、“服务注册中心”连接。“服务消费者”只管去找 API Gateway 访问即可。至于去注册中心查询服务地址,以及访问服务地址的动作都由 API Gateway 代劳了,最后 API Gateway 在把结果返回给“服务消费者”即可。 

    服务分布,流程聚合:集中式的服务配置管理

     

    服务运行通常要设定一些参数,这些参数以往以配置文件的形式存在。此外,我们在进行业务开发的时候,一般会有多个环境,例如开发环境、测试环境、生产环境,这是传统的配置文件无法解决的。 

    集中式的服务配置管理,让我们告别投产或运维手工修改配置的方式,统一管理所有微服务节点的配置,提升运维的效率。 

    配置文件主要有运行前的静态配置和运行期的动态配置两种。静态配置通常是在编译部署包之前设置好。动态配置则是系统运行过程中需要调整系统变量或者业务参数。要想做到集中的配置管理,需要注意以下几点:

    1)配置与介质分离,这个就需要通过制定规范的方式来控制。千万别把配置放在Jar包里。

    2)配置的方式要统一,格式、读写方式、变更热更新的模式尽量统一,要采用统一的配置框。

    3)运行时需要有个配置中心来统一管理业务系统中的配置信息,这个就需要平台来提供配置中心服务和配置管理门户。 

    数据分布与信息聚合

     

    数据是企业应用的核心,企业应用也是围绕着数据展开,当系统数据越来越庞大的时候,我们就需要考虑将数据拆分,分而治之。表面上使用微服务架构后,必然出现数据的分布,实际上正是由于数据需要分布,才产生了微服务架构。一方面,随着目前移动互联网、物联网的发展导致数据量越来越大,另一方面“下主机”“自主可控”等架构要求导致单机处理能力有所降低,因此需要进行数据分布。 

    根据 CAP 原理,一致性、可用性、分区容忍性三者无法同时满足,我们不奢望找到全能的方案,但可以应该根据不同场景归集到几种模式,制定相应的处理策略。 

    1.数据分布的模式

    数据分布主要有两种模式,垂直拆分与水平拆分。

    2. 保证数据一致性的模式 

    (一)可靠事件模式

    (二)业务补偿模式

    (三)TCC模式(Try-Confirm-Cancel)

    上述几种模式,经常有人提到下面的问题:

    1)都要求服务提供者在正常的交易之外,提供额外的功能,貌似带来了代码的复杂度,加大了工作量。实际上都是业务需求中必备的,例如:TCC 模式在交易系统中都有预扣款这样的接口,并不会增加实现的工作量。而对于服务的调用者来说,相关服务的调用由微服务框架实现,例如自动的事件投放、自动补偿调用、TCC中 CC 服务的调用,也不需要额外的工作量;

    2)如何从当前上下文向补偿接口、confirm接口、cancel 接口传递参数?实际上只要将正向交易的数据传递过去即可,不需要额外的数据;

    3)如果补偿还是失败,该怎么办?还是需要对账的。

     

    分布式感觉能力的相关技术

     

    建立感觉能力可以概括为以下四种方式:

    1)心跳监测:提供模拟交易,由系统主动提供运行状态信息。

    2)日志记录:系统将运行情况记录下来,用于感觉后端服务的运行情况。

    3)字节码注入:注入到服务端代码中,用于感觉后端服务的运行情况。

    4)客户端埋点:注入到客户端代码中,用于感觉前端的运行情况。

    聚合式知觉能力的相关技术

    “感觉”探查到的信息汇总形成完整的“知觉”,例如:

    1)健康检查:知晓微服务健康状态,了解服务的可用性,避免调用到失效服务上。

    2)性能分析:知晓微服务运行的性能,了解整个系统的瓶颈,在实时分析的基础上进行预警,在问题萌芽的阶段发觉并告警,降低问题影响的范围和时间。

    3)业务监控:知晓业务交易情况,监测业务访问量、慢交易数量、业务时延及发生错误的次数等各项业务指标。

    4)故障定位:知晓微服务的拓扑结构、调用关系和调用顺序,实时搜集信息并进行聚合分析,了解系统和应用中发生的事件,尽量避免故障,并且在发生故障后快速定位故障,减少处理时间。

    建立微服务架构下系统的知觉能力,需要多个层面配合完成,是一个系统性的工程,而不是孤立的考虑。我们把系统的“知觉”能力纵向分为四个层次,客户端(Web、H5、APP、小程序等)、服务端(微服务进程)、技术组件(虚机、容器、中间件、数据库等)、基础设施(网络、服务器、存储等)。“知觉”体现的最终行动,分为链路拓扑、监控、预警、故障定位、趋势分析等几个主题;配置中心(CMDB)实现所有涉及到的应用软件、系统软件、服务器和网络设备的配置管理、监控参数设置、业务规则配置,监控中心负责监控展示与告警;分析中心根据“感觉”采集的数据进行深度挖掘,积累知识。 

    推荐阅读

    数据中台建设从数据中台的认知开始

    业务中台建设从结构化需求开始

    数字化中台建设的过程与方法

    关于作者:黄荣,数字化金融研究院研究员,擅长系统分析和架构设计、金融三级密钥安全体系及信息安全保障、虚拟化和云计算技术、JavaEE技术;参与研发的神州商桥电子商务平台获得“全国电子商务示范单位”称号;带领团队研发的国电通云终端系统在国网多个省公司推广应用。

    关于EAWorld:微服务,DevOps,数据治理,移动架构原创技术分享。长按二维码关注!

    展开全文
  • 2、京东服务技术中台建设思路;3、关于中台建设的个人思考。为什么要做服务技术中台呢?举个例子,假设一个用户在京东买了东西,但不满意,希望退换货。他会通过在线聊天、电话找到客服,客服会对其进行接待,并将...
  • 上一篇中台系列的文章重点阐述了中台的概念,本文是系列文章的第二篇,目的是说明什么情况下可以考虑建设中台,如果要建怎么建的问题,可以作为企业思考中台建设的大框架。以下为原文(有少量改动): 本文将例举...

    编者按:本文转载自网易副总裁,网易杭州研究院执行院长汪源的个人公众号“冷技术热思考”(欢迎搜索关注)。上一篇中台系列的文章重点阐述了中台的概念,本文是系列文章的第二篇,目的是说明什么情况下可以考虑建设中台,如果要建怎么建的问题,可以作为企业思考中台建设的大框架。以下为原文(有少量改动):

    本文将例举典型的需要建设中台的场景,供参考判断要不要建中台。建设中台需要考虑组织、技术支撑和方法论,往往还需要咨询服务的帮助,本文也可以作为思考中台建设的大框架。

    要不要建设中台?

    要建设中台,首先要考虑要不要建设中台。话说的这么绕是因为现在有很多不明就理就想建中台的。这个问题先做个初略的判断。

    01业务中台的典型场景

    对业务中台来说,比较符合的场景主要有: 
    · 业务系统研发团队至少大几十人(含外包的),需求多变化快,系统又涉及多个领域(比如做ERP、电商的),业务逻辑比较复杂。这时业务中台可以把系统和业务领域划分清楚,提高研发效率。 
    · 做相似行业的外包项目为主,业务规模也做的比较大的(一年有两位数的项目)。这时业务中台可以提升软件复用,降低定制化成本,提高研发效率。如果你做外包,每个项目都完全不一样,那中台也救不了你。 

    此外还有以下场景可能不需要建设完整的中台,但适合落地与中台相关的微服务技术的: 
    ·  大规模互联网式在线系统,对稳定性和弹性要求高当前搞不定的。微服务或业务中台可以比较好的解决这些问题。 
    ·  掉到IT竖井的坑里想爬出来的,通过项目外包做的系统无法管理和维护的。微服务或业务中台可以对系统的API、文档等进行有效管理,也能实现系统间的打通。 

    02数据中台的典型场景

    对数据中台来说,比较符合的场景主要是数据产品比较多,每天要看数据如果没数据就不知道怎么工作的运营人员比较多的业务。比如电商就是典型。如果这些数据产品和运营人员还在多个团队,那基本上数据中台没跑了。如果经常出现指标不一致、数据出错、想要的数据不知道哪里有等问题,那基本上数据中台也没跑了。

     


    并不是数据量大就需要建中台,主要还是看用数据的姿势是不是比较复杂,当前问题是不是比较多。对于这类符合的业务,数据中台能把层层数据直到最上层的指标梳理清楚,提升数据质量,从而提升运营效率。把数据理清楚了,往往还能降低数据存储和数据开发人员的成本。


    除了上述判断,还有一条是同行对比。如果一个行业大家都有点跃跃欲试想弄中台,那领先者一定要想办法抢先(既然是领先者了,往往也符合上述标准),不然就可能被颠覆。跟随者要不要想办法抢先从而超越领先者呢?可能不好说吧,但如果领先者已经建了,跟随者一般得紧跟,否则真可能被甩开了。


    如果根据上述逻辑觉得大致要考虑去搞一把中台的话,那请继续读本文以下内容,读完本文后续内容然后更具体的看看问题存不存在,条件是否具备。要建设中台,需要考虑组织、支撑技术、方法论这三个方面,往往还需要咨询服务。

    中台组织

    中台作为一种有业务属性的共性能力,首先就需要一个懂业务、承担业务职责的专职的组织机构来负责。要不要建中台,首先要看领导有没有魄力去整合建立一个中台组织。因为原来的平台部通常不懂业务,懂业务的人各自分散在前台业务部门,所以建立中台组织往往涉及人员、组织架构和部门职责的调整。 正因为如此,中台的建设往往需要作为一把手工程才能成功。


    中台组织关键要懂业务和承担业务职责。举个例子,一个大数据平台的建设运维团队不是一个中台组织。一个团队如果做了非常完善的中台产品(如开发了数据中台所需要的指标管理系统、数据仓库开发系统、数据质量管理系统等等),但只是把产品提供给业务方使用,这个团队仍然不能说是中台组织。只有当这个团队承担起指标体系的建设和管理、数据仓库的设计和实施、数据质量的保障等工作时,才可以说是中台组织。而要做到这一点,这个组织肯定是比较了解业务的,它的目标和考核也一定与业务有相关性(肯定不只是平台稳定性这样的非业务指标)。


    中台组织的层次与中台的层次最好是对应的,BU级的中台组织最好直接向BU老大或分管的CXO汇报,企业的中台组织最好直接向CEO或分管的CXO汇报。


    这里特别说明一点的是如果不建设在线业务中台,而只是采用微服务、云原生等技术的话,可以不涉及组织方面的大规模变动,就在原来的研发部实现转型。通常来说也可以实现一定的系统可用率、弹性和研发效率方面的提升。

    中台建设的支撑技术

    建设中台一般需要一套支撑技术。 

    01在线业务中台支撑技术

    建设在线业务中台一般需要云原生、DevOps、微服务技术体系的支撑,这是因为: 
    · 微服务技术:中台是一个独立的组织负责并为多个前台业务服务,因此需要一个标准的服务接口、成熟的服务治理能力和高效的敏捷研发技术。在当前的技术环境下,采用地球人都熟悉的REST风格的同步API、消息队列异步通信作为标准的服务接口技术,采用服务框架(如Spring Cloud等)、API网关、APM等作为标准的服务治理和敏捷研发技术是最合适的选择。不再建议采用传统的基于ESB的服务化(SOA)技术,因为ESB产品过多的介入到业务逻辑中,导致前台业务的变更往往需要中台团队的配合才能完成,这样就失去了建设好中台,支撑前台高效创新的意义。此外,中心化的ESB软件和复杂的基于XML的WS-xxx等协议也影响到系统的可用性和性能。可以参见Martin Fowler在P of EAA中的评价,Web Services是应用集成而非应用开发的技术。 
    · DevOps技术:如果不通过DevOps使得各微服务都能自助式的部署更新,则微服务带来的敏捷性就无从发挥,反而因为服务数量的增加导致研发效率的下降,因此持续集成、持续发布等DevOps技术一般是实现微服务的必备。 
    · 云原生技术:微服务和DevOps要求底层的基础设施是灵活可编程的,否则根据Amdahl定律,只要有一个必须的环节是低效的,整体的效能也提不上去。 
    需要强调的是中台要敏捷,这一方面是因为中台具备业务属性,且支撑了非常丰富的前台业务,前台业务的敏捷性要求有一部分就会传导的中台层;另一方面是中台的重要性使得其需要持续不断的优化,即便对外提供的服务不变,内部实现也会经常变。 
    · 分布式事务技术:实施微服务拆分后,复杂的业务流程不再能通过数据库的事务机制来实现ACID特性,为此还需要服务层面的分布式事务处理技术。典型的分布式事务处理模型包括TCC、Saga、FMT等。其中TCC和Saga需要各服务实现定制化回滚逻辑,侵入性比较严重,用起来门槛比较高。FMT模式对于Java可以做到加一行注解(如@GlobalTransaction)即可实现分布式事务,剩下的由框架自动处理,用起来方便的多。Saga模式是Princeton的两位研究者在1987年提出的,灵活性和并发度最好,但需要通过语义锁等精细的设计才能发挥出来。 

    由此可见,在线业务中台的技术支撑体系是相当复杂的,所幸的是Netflix、Google等世界领先的互联网企业由于自身业务需要打造了很多实用的技术模块,开源社区也贡献了不少力量,CNCF组织又做了很好的汇集和标准化。 通过将相关技术加以整合,已经有了不错的产品可用,如网易轻舟微服务就是一套产品化设计良好、功能丰富的在线业务中台支撑技术产品。

    一般而言,前台也会和在线业务中台一样采用云原生等同样的技术体系,这是因为前台更需要敏捷性。在完善的中台支撑之下,前台会比较轻,还可以考虑采用FaaS Serverless技术,不过目前这方面的实践还不多(特别在中国),相关的支撑技术也不是很成熟。 

    02数据中台支撑技术

    建设数据中台一般需要一整套如下典型的支撑技术: 
    · 指标管理系统:指标是中台与前台之间最关键的接口,也是建设数据中台的牛鼻子,因为它是最核心的业务语言,且指标不一致、数据常出错是建设数据中台最常见的出发点。如果指标体系没有统一的方法论,进行统一建设,那么就很难说是数据中台。指标管理系统一般要实现一套一致的方法论(如原子 / 派生 / 复合指标、维度、修饰词等),做好指标的业务和技术口径管理,还需要支持指标的审批管理。数据中台的指标无法交给各前台业务自助式的建设。 
    · 数据服务系统:类似于在线业务中台需要通过API网关提供标准化的服务,数据中台也需要一个标准化的服务方式,通常称为数据服务系统,也可以说是数据网关或数据门户。类似于别的网关类产品,数据服务系统需要提供鉴权、日志审计、流控、协议转换(如SQL Dialect之间的转换)等功能,也应该发展多引擎融合查询、逻辑模型等扩展功能以提高服务接口的稳定性和实现的灵活性。 
    · 元数据管理系统:元数据管理是整个数据中台的基础和中心,所有的其他系统都依赖元数据管理。元数据管理首先要做好的当然是数据模式或目录(catalog)的管理,至少要知道中台里都有什么数据。对复杂的数据中台来说,数据血缘也很重要。没有血缘信息,不知道数据间的依赖关系,数据质量肯定管不好,因为不知道一个数据的质量问题怎么来,又进而会影响什么。同样的如果没有血缘,数据资产也肯定管不好,因为不知道什么数据有价值什么没价值,这就像如果你不知道一个函数被谁调用,你就不知道它是不是死代码一样。元数据管理系统往往也需要提供一个基础的访问界面,通常称之为数据地图。 
    · 数据仓库开发与管理系统:除了指标管理,数据仓库的开发是将一大堆初始数据建设梳理成一个漂亮的数据中台的核心过程。一般来讲数据中台更适合用Kimball的维度建模方法而非数据仓库之父Bill Inmon所提倡的方法,这是因为Inmon强调顶层设计,而Kimball强调至下而上。如果要建设数据中台,肯定是因为前台业务复杂多变,这时强调顶层设计会导致中台建设缓慢、僵化。因为中台虽然应该是由组织高层决策,但目的却是为了支持前台业务,而不是为了控制。 支持而不是控制,这一点绝不能本末倒置。 
    · 数据质量管理系统:所有复杂的系统都需要专业的质量管理,在线业务系统有一系列的弹力设计和APM等监控运维工具,数据中台也需要专业的质量管理。数据质量管理系统通常设计为支持丰富的稽核 / 校验 / 比对规则,监控数据是否准确、实时、一致,还要做到及时的报警,分析影响面,提供快速修复的手段等。但这些手段只能发现和补救问题,不能预防问题,要预防问题,还要通过测试工具减少代码bug、通过资源弹性应对性能波动、通过优先级调度优先满足重要业务需求等。相对来说,当前数据中台领域的质量管理没有在线业务领域的成熟,如在线业务领域的测试手段远比数据领域的精细,在线业务领域很常见的熔断、限流、服务降级等模式在数据领域都没有成熟的实践方法(优先级调度可以说是实现了部分的服务降级功能),随着数据中台越来越广泛和重要,这些技术应该也需要持续发展,但技术上的挑战不小。 
    · 数据安全管理系统:数据中台因为汇集了组织所有有价值的数据资产,因此良好的安全管理是必须的。细粒度的权限和审计是基础,一般的还需要隐私 / 敏感数据的脱敏处理、数据加密(特别是将数据托管在第三方平台之上时)、数据泄漏防护(比方说一种常见的方法是限制将数据下载到本地的数据量)等技术。发展到高级阶段甚至可能还需要联邦学习、数据沙盒等技术。 
    · 数据资产管理系统:在数据质量和安全单列的情况下,数据资产管理主要负责的是数据的生命周期管理、成本的统计分析与优化等工作。


    同时,数据中台还需要强大的大数据计算引擎、数据集成 / 同步 / 交换引擎,还往往需要一套敏捷BI系统:
    · 大数据计算引擎:数据中台要管理的数据规模和复杂度往往都很高(否则搞中台属于为赋新词强说愁),所以传统的数据库和数据仓库基本上支撑不了。当前的技术环境下,基于Hadoop MapReduce或Spark几乎是唯二的选择,当然这也包括了这两者之上的Hive和Spark SQL。能用SQL就用SQL,易于维护,也易于数据血缘的收集。除此之外,流处理可能还需要Flink,交互式查询可能要引入Impala或GreenPlum。
    · 数据集成 / 同步 / 交换引擎:一方面数据中台需要强大的数据集成和同步能力才能吸纳各方数据。集成和同步的概念相近,同步更强调实时性。另一方面,数据中台往往由多种数据计算引擎构成,就需要同步或交换引擎实现不同引擎见的数据交换。
    · 敏捷BI系统:建设数据中台通常最重要的目的是为了支持业务运营和决策,为此需要基于数据中台进一步开发数据产品。敏捷BI系统是开发数据产品快速、轻型的手段,能够尽快尽早的发挥数据中台的价值。


    此外,对于互联网业务,统一的埋点引擎往往也是数据中台所需要的。如果埋点的逻辑都不统一的话,建数据中台的时候会发现数据的源头就是乱的,后续也都没法做。其他行业业务,数据采集也属于基础工作,也是要先做好的。


    由此可见,建设数据中台需要的技术支撑体系也是相当的庞大,复杂。所幸的是这十年来Google等领先的企业、Hadoop / Spark等开源社区以及大量的厂商大致联合探索出了一条可行的路径,方法论和技术路线都比较统一了。以此为基础,就可以提供较成熟的数据中台技术支撑产品,如网易杭研研发的“网易猛犸V6.0 + 网易有数”就是一套较完整的数据中台产品。

    中台建设的方法论

    复杂事务都需要方法论的指导(和约束),组织管理有虚虚实实的一大套各种理论,研发有敏捷方法或IPD流程,中台是复杂事务,所以也需要方法论。因为中台建设涉及组织和技术两个维度,所以中台的方法论也应该要覆盖这两个维度。目前而言,技术维度的方法论相对成熟,因为复用了很多原有的方法论。 

    01在线业务中台方法论

    对于业务中台,微服务、网关、REST API及语义化版本控制、六边形架构是侧重于技术架构的方法论,DevOps、敏捷项目管理是侧重于流程层面的方法论,领域驱动设计(DDD)是侧重于业务架构的方法论。要做好业务中台,以上方法论大概都不可或缺。 
    大家可以看到,除了微服务跟中台大致是同步发展的之外,其他方法论都是早前就存在的东西。正因为有这么多合适的方法论存在,中台才变得可行,无论如何在短期内要发展出这么多方法论是不现实的,因为方法论的威力不仅在于它要好,还在于它要流行。 

    技术架构和流程方面的方法论已经很流行,无需多说(六边形架构放在和DDD一起介绍)。值得关注的是领域驱动设计这么一个10多年前就被提出,这么多年一直不温不火的方法论,突然在中台领域似乎找到了它的最佳安身之所。这样的现象是会昙花一现,还是会长期持续,值得思考。 

    DDD的核心概念是通用语言和限界上下文。通用语言指的是在一个业务领域内通用(但不是在更大的领域内也完全通用的)的概念、术语等语言,限界上下文指的是相邻通用语言之间“翻译”的边界,比如前台业务的用户可能要变成后台清算的客户。 

    我觉得DDD的通用语言和一直以来的领域建模是比较相似的,更具创新意义的是限界上下文。在架构设计中,我们要不要构造那种拥有非常多属性,但每个使用者只使用少量属性,或者属性的名称和含义对使用者来说不贴切的对象?如果没有限界上下文的约束,可能会认为这样毕竟实现了更多的复用,是好的,但用限界上下文的理念来看,这样很可能是不好的。每个领域应该专注于自己领域的语言,领域之间要交互怎么办?加一种翻译机制,也就是限界上下文解决。 

    领域驱动和限界上下文的理念会自然延伸出六边形架构的设计。所谓六边形架构指的是一个程序的内部只需要处理业务逻辑,他的数据 / 请求从哪里来,数据要存储到哪里去(或者领域事件要发布),都通过各种适配器完成。因为这样的适配器可能较多,就不再像传统的三层(三明治)架构。不过如果六边形只有一个Input和一个Output适配器的话,和三层架构就还是差不多的。我想从三层架构进化到六边形架构的主要原因还是因为现在的环境已经从传统的C / S或B / S这样只有一个前端,也只有RDBMS这样的一个后端发展到前面有Web / 移动等多个端,向后也有RDBMS / NoSQL等多个端,横向也有服务化 / MQ等多个端的多端环境。我不知道哪天会不会发展出一个十面埋伏架构出来。 

    02数据中台方法论

    数据中台的方法论也是博采众长,最核心的来自于数据仓库领域关于数据仓库规划实施和指标体系建设的方法。在数据仓库领域,有两套截然不同的方法之前一直是较劲的,一个是数据仓库之父Bill Inmon所倡导的至上而下的方法,另一个是另一位大师级人物Kimball所倡导的至下而上的方法。在我理解,所谓Kimball的模式之所以说是至下而上,是因为基本上中台团队只负责从ODS到DWD到DWS就完了,往上就是所谓的ADS,其实已经是面向各个业务(或者数据产品)了。你都可以说ADS层不属于数仓。这样的方法在中台作为一种新生事务没法有很强的话语权时显然是更容易做出的选择,可能未来中台概念深入人心,集团高度重视,说不定Inmon方法又会重新流行?但也可以思考这种细节上都体现了领导的管理意志的中台还是中台吗。指标设计的方法论基于Kimball方法中的粒度建模的方法,做了比较大的细化和改进。 

    划分主题域是建数据中台的常见实践,不过主题域划分与行业强相关,比如对零售业常见的有商品、交易、流量、用户、营销等域。 

    数据中台统一通过数据服务系统实现OneService的设计,不清楚有什么来源,不过类似于在业务架构中很常见的网关模式。数据质量、数据安全、元数据、生命周期管理也都是数据治理领域比较常见的概念,但一方面要实现针对大数据技术环境的落地,另一方面更面向业务支持而非管控来设计。 

    实施数据中台通常还需要制定很多规范或标准,这也可以说是方法论的一方面。有很多规范是命名规范,其中数量最大的往往是数据仓库中的表,上万张表甚至更多都是很常见的,所以表的规范命名非常必要。一种好的表的命名规范,要反映其所在数仓分层、主题域、业务过程、时间周期等信息。计算任务也需要一定的命名规范。数据埋点也需要规范性的编码位置信息、内容信息和事件信息。 

    03组织维度的方法论及其他业

    其他类型的中台也都有各自的方法论。如搜索中台,B公司有比较详细的对外分享的资料,其方法论主要体现在规范了搜索系统的关键流程,如内容引入和加工、离线训练、在线召回和排序等,还会涉及到查询改写、展示设计等要点。 

    以上说的都是中台技术维度的方法论,组织维度的方法论目前还没有看到好的系统性分析成果。在《企业IT架构转型之道》中只有很少的篇幅介绍中台组织维度的方法论,在另一本讲数据中台的书中,干脆就只字没提组织方面的内容。业界关于中台组织的方法论,主要包括多职能小微团队、业务架构师主导、协作沟通机制、轮岗、共建、考核机制等。业界也有从一般性的组织管理维度(如垂直型组织、矩阵型组织等等)分析,过于宽泛,说了等于没说。 

    中台组织层面的方法论可能是相对不成熟的,比如中台和前台、平台之间的边界和动向问题,似乎没有明确的方法。我认为可能主流会符合“前台->中台->平台“单向流动的中心法则。可能中台组织的终极目标是发展为平台,因为还是要追求把能力做成熟和标准,我这也可能是很反动的说法。 

    作为集团的创新业务孵化中心,网易杭研每时每刻都针对很多业务线要并行发展,为此打造了一个又一个共享能力中心,千方百计提升创新效率。12年来感觉摸索了一些关于中台的建设经验,当然可能更多的是教训,这段经历的体会后续我将会做个梳理,发出来供大家讨论。 

    中台建设的咨询服务

    说到咨询,我首先想到的是技术进步的驱动力发生了很大的变化,从厂商和咨询公司驱动变成了领先客户驱动。以在线业务为例,传统的SOA和Web Services技术是传统厂商驱动的。这些厂商自己不用产品但要卖产品,所以一不小心就把产品搞的不必要的复杂。另外这些厂商和咨询公司本来就是共生共荣的关系,所以也得把产品搞的复杂一点吧,不然咨询公司就没生意了。新生代的微服务技术主要是领先的互联网企业驱动的,自己造产品自己用,能简单一点就简单一点,最好是做成各个业务部门自己就能用。 

    所以新生代的中台技术是尽力将咨询的必要性尽量降低的,但是因为当前实践中台的都是很大的互联网企业,业务复杂度不可避免的很高,对于大多数想要实践中台的非互联网企业来说,仍然是需要咨询服务。 

    现状是,当前中台的咨询非常欠缺。因为这些中台都是互联网企业搞的,当前的厂商和咨询公司都没什么能力做这块的咨询。我们可以看到一些咨询公司,不懂中台,把什么都往中台的概念上凑。当前也就互联网企业或有很强互联网企业背景的团队才有能力做咨询,但资源很有限。希望咨询公司们能够聚焦于真正的中台,透彻理解什么是中台,提升自己的咨询能力。 

    作者简介

    网易副总裁,网易杭州研究院执行院长 汪源 
    2006年获浙江大学计算机专业博士学位,之后加入网易公司。现作为网易杭州研究院执行院长,全面负责网易集团公共技术支撑工作与云计算、大数据业务,主要包括云计算与服务端架构、前端技术、大数据挖掘分析、信息安全、多媒体、运维、质量保障等方向。

    点击链接更多关于网易数据中台

     

    展开全文
  • 数据中台是泛在电力物联网重要基础支撑性平台,2019年公司统一组织完成数据中台技术能力规划及产品选型,在全业务统一数据中心分析域已有组件基础上,引入阿里、华为成熟产品,完善数据中台组件体系。
  • 技术中台的作用是什么? 技术前台 技术中台 在什么情况下,才有必要做技术中台? | 前提1:技术组织结构垂直化 | 前提2:业务线又多又复杂 有了技术中台,是不是就能上天? 总结 就在刚过去的半年里,「...

    目录

    技术中台的作用是什么?

    技术前台

    技术中台

    在什么情况下,才有必要做技术中台?

    | 前提1:技术组织结构垂直化

    | 前提2:业务线又多又复杂

    有了技术中台,是不是就能上天?

    总结


     

    就在刚过去的半年里,「中台」成了技术圈内讨论的热门词汇,就连一些名不见经传的小公司,也都纷纷喊出了「要向中台转型!」的口号,甚至有人说「不做中台,那就等着死吧!」

    如果我没有记错,「中台」思想源自于2015年,马云参观一个著名的游戏公司Supercell之后提出了,简言之就是“小前台、大中台”,随即阿里就成立中台事业群,并取得了很好的成效。

    随后,美团点评也开始走中台策略,腾讯在去年的组织架构调整中,也提出建设具有 “腾讯特色的技术中台”。

    技术中台的作用是什么?

    要搞明白这点,你需要先搞清楚「技术前台」、「技术中台」与 「技术后台」 之间的关系,以及他们各自扮演的角色与作用。

    先来说说我们的「技术前台」。

    技术前台

    「技术前台」,说白了就是为业务部门开发功能的技术团队。

    如果是ToC的业务,交付物必须贴近终端用户,如果是ToB的业务,交付物需要满足商家的需求。

    脑海中必须时刻牢记 “小步快跑,快速试错” 的理念,业务说啥,就是啥,业务要怎么做,你就怎么做。

    另外,研发资源的投入基本和业务对等,业务需求多,人数增加,业务需求少,人数相应减少,而且团队组织也基本按功能线来划分。

    运用的技术栈也相对单一,以Java语言为例,通常 “1个NG + 1个War/N个Jar + 1个数据库” 就搞定了,而其余的技术服务都将由「技术中台」提供。

    「技术前台」的核心价值体现在对业务逻辑的理解与实现上,是技术向业务传递价值的阶梯。

    我觉得在这点上,与线下销售团队的前台营销有一些类似。

    技术中台

    再来说说我们的「技术中台」。

    「技术中台」,说白了就是强调资源整合、能力沉淀的平台体系,当「技术前台」实现业务功能时,为他们提供底层的技术、数据等资源和能力的支持。

    这怎么理解?

    从这张图中可以看到,「技术中台」有点像编程时的适配层,起到承上启下的作用,将整个公司的技术能力与业务能力分离,并以产品化方式向前台提供技术赋能,形成强力支撑。

    在什么情况下,才有必要做技术中台?

    俗话说 “知己知彼,百战不殆”,在我看来,面对技术问题时,“知己” 比 “知彼” 更为重要。

    在实施「技术中台」之前,我们是否要静下心来对自己进行 “灵魂拷问”?比如说,当前的时机是否已经成熟?或者怎么才叫成熟?

    在我看来,要想做「技术中台」,客观环境需先满足两个前提:技术组织结构垂直化业务线又多又复杂

    否则,「技术中台」的结果只会是两种:一场闹剧 或者 一笔赔钱的买卖。

    | 前提1:技术组织结构垂直化

    曾经有朋友说过,每家公司的组织结构演进都是一部心酸血泪史。我很费解,问为什么?

    他说,因为这中间掺杂着太多的主观判断与情感纠葛。

    比如,某员工认为公司管理混乱,组织架构来回调整,今天拆这个团队,明天合那个团队,纯属病急乱投医,高管都是些横行霸道,滥用资源的傻逼货,借机搞人,这公司,没救了。

    但高管们大呼冤枉,觉得组织架构调整的目的是为了提高产出和人效,如果你干得不爽可以离开,这种事情,本来就不可能让每个人都满意,既得利益者肯定大加赞赏,而失去利益者肯定狂喷不止,不用理会。

    的确,这种 “自我革命式” 的调整,基本不可能一步到位,需要一个过程慢慢演化,而在这个过程里,自然会遭遇很多的阻力或质疑。

    瞧瞧这结构,经典的职能分工模式,有什么问题吗?

    我不但说不出问题,甚至能找出一万个理由说明这种模式的好处。开发按业务线分开,测试与运维形成上下层关系,谁也不想管对方,两边的老大也是评级的,相安无事

    那什么情况下才会觉得这种模式有问题呢?

    客观的说,职能分工模式更适合瀑布式开发模式。先谈需求,再谈工期,随后按部就班地往下做

    但当用户的需求开始变的多种多样,业务方时不时的就要上一个新功能,做一个新系统的时候,你会发现开发出来的系统很难变更,至少很难快速变更。

    于是,你把开发按系统功能进行重组,每个团队都围绕 “交付速度” 开展工作,但这样又遇到了两个新的问题:

    • 多种多样的中间件,每个团队独立选型中间件,没有统一的维护,没有统一的知识积累,无法统一保障SLA。

    • 开发与测试、运维之间目标不一致(比如测试A君,开发要求你只做功能测试,快上线,但测试老大却要求你做非功能测试,保障质量,避免背锅……到底听谁的?),陷入永无休止的扯皮与争吵。

    面对这两个新的问题,我们做出了调整:

    • 成立平台架构组,负责中间件、自动化测试/运维、数据库等技术工具或服务的开发、维护。

    • 把质量管理部中的测试团队,与系统运维部中的应用运维团队,按照系统功能拆分至各开发团队,由原开发经理负责,形成各自独立的Feature Team。

    到这个时候,虽然整个组织结构还未完全实现垂直化分工,但已基本能够达到 “快速试错,小步快跑” 的目标。

    另外,这更像平台化的另一种雏形,就是逐渐把一些公共、底层的技术能力抽象出来,与业务逻辑分离,并形成各种接入式基础服务,同时可以为多个业务线提供服务。

    也就是说,打造「技术中台」的前提是平台化,而平台化的先决条件是「组织结构垂直化,技术工具公共化」

    如果没有这样的前提,就失去了打造「技术中台」的立身之基。

    | 前提2:业务线又多又复杂

    曾经有朋友问我,技术的核心价值是什么?我的答案是 “改变世界”。

    他说,别扯淡,好好说话。

    他说,对业务驱动型的公司来说,技术的核心价值是 “降低成本,提升效率”,而单从架构设计的角度来看,想达成这项目标的两个手段是「通用性」与「复用性」

    现在想想,这句话可以完美的衔接到「技术中台」上去。

    回顾几年前,我们的业务逻辑也曾非常单一,要么用你的银行卡买卖基金,要么用你的电子钱包买卖基金,方便,快捷。

    渐渐地,随着业务创新业务增多,需要前后台系统定制开发,逻辑兼容难度增加。

    在这样的局势下,为满足企业规模扩大和多样化经营对组织机构的要求,公司开始转向事业部制,按产品、地区或市场(顾客) 划分经营单位。

    为了应对业务方的这次调整,我们开始将业务开发中的一些共享服务分离出来,成立了业务中台组(由于本文以技术中台为主,业务中台的内容将不进行展开说明)

    将可以复用的服务和代码,交由这几个组开发出服务来,给业务组使用,这样数据模型会统一,业务开发的时候,首先先看看有哪些现成的服务可以使用,不用全部从零开发,也会提高开发效率。

    与「业务中台」相呼应,「技术中台」就像一个工具大仓库,里面放满了各式各样的技术工具,无论是哪个团队,哪个人,快速找到自己的工具,拿来就用就行了。

    而维护工具的这群人,不用贴近业务开发,每天的任务就是研究如何使用这些工具,如何调优,遇到问题如何Debug,形成知识积累。

    有了这么一群专职的人,就可以根据自身的情况,选择有限几个技术栈集中研究,限定业务组只使用这些工具,可保证选型的一致性。

    如果你只有一条业务线,那就别搞「技术中台」了,把人凑在一堆,又省钱,又省力。

    有了技术中台,是不是就能上天?

    理论上讲,当业务线变多且越来越复杂,前台与后台之间的“技术债”会随之变多,重复造轮子与沟通成本太高的现象会增多,通过技术中台可以一定程度上来解决这个问题。

    这种理论看似完美,但在实际执行上却困难重重。

    设想下,如果「技术中台」做得太多,资源投入就会很大,无法形成正向的利益传导;

    如果「技术中台」做得太少,又无法深入理解业务,导致适配方案落地性变差,渐渐失去价值。

    这句话怎么理解?

    十年前,我在某金融软件公司工作,随着客户数的增多,成本与效率/质量的矛盾日益凸显。

    设想下,从一波人维护一套代码,渐渐变成一波人维护几套代码,这样一来,Bug增多,效率下降,抱怨也随之变多,再加上甲方挖人,最后人员离职,团队土崩瓦解,Game Over……

    在这种情况下,一般公司会采取三种应对措施:

    1. 一对一服务 - 项目制:多个团队,多套代码,多套标准,服务多家客户,但这样一来成本又难以承受,时间一长,肯定资不抵债。

    2. 一对多服务 - 标准化:一个团队,一套代码,一套标准,服务多家客户,但客户不买账,客户说我的需求都是个性化的,你别来某某标准来引导我,叫你咋做,你就咋做,不愿意?那您走,我找别人家做。

    3. 一对多服务 - 产品化:一个团队,一套代码,多套标准,服务多家客户,通过技术与配置化的手段,利用SOA思想,打造自己的产品化平台,但对技术投入要求较高,尤其是核心人才的依赖较大,中小型企业一般都很难留住这些人,只要他们一走,公司基本完蛋。

    回想下,当年那些叱诧风云的软件公司,又有几家活下来了?以金融业为例,恒生算是在第二条路上走的比较成功的,而我们当年却死在了第三条路上。

    在我看来,我们的「技术中台」就是一家 “乙方服务公司”,而我们的「技术前台」更像是一家 “甲方电商公司”。

    不可否认,有了这家 “乙方服务公司” 之后,在面对大型项目及快速多变的业务时,技术的投入与主动权更强了,但由于理念、职责、节奏与使命不同,外加 “屁股决定脑袋” 的立场,前台与中台之间很容易引发矛盾。

    从职责角度来说,前台是 “快速应对业务变化”,中台是 “稳定高效提供服务”。

    一个追求效率,一个追求质量,这矛盾是天然存在的。

    怎么理解?我来举个小例子说明下。

    前台部门的A团队和B团队,由于业务需要同时向「技术中台」提出要接入缓存服务的需求

    「技术中台」的中间件产品线中有一套基于Proxy的自研分布式缓存系统,已在其他业务线运行多年,但由于A团队与B团队的技术债都各不相同,必须通过增加适配器才能完成接入

    而此时人手又不够,按重要程度排序,只能先接A团队,但B团队也有需求,又等不及,怎么办呢?就先给他来个Redis接着玩玩吧,等A团队接好了再来接你的。

    一个月后,等A团队接完了,找到B团队,这时痛点已不存在,团队的激情自然不高,毕竟没有收益,就不了了之了。

    几个月后,安全团队提出要对Redis集群进行改密,由于A团队接入的是「技术中台」的缓存中间件产品,采用代理模式,并通过控制台操作,既方便,又快捷,找个晚上,5分钟内,全部搞定。

    但B团队用的是直连Redis的模式,密码嵌入在SDK中,不仅在改密过程中需要前台与中台联动,而且还需要在改密后重启应用服务,这样一来,只有配合应用发布的周期才能干这件事。

    最终,原本五分钟可以搞定的事,整整搞了三周才搞定,「技术中台」的运维同学更是陪熬了多次通宵,还因为人为疏忽引发了一次事故。

    就在这件事过去的一年时间里,由于B团队系统的业务规模逐渐增大,Redis数量也逐渐增多,「技术中台」的运维成本与风险也随之上涨。

    这期间,中台曾多次与前台交涉,希望能够通过适配的方式将A团队接入缓存中间件,但始终未能达成。

    在「技术中台」看来,“你们只顾自己,不管别人,功劳你们拿,黑锅我们背?”

    在「技术前台」看来,“你TM懂个屁!我们都快被业务逼疯了,你们不就多费点人工吗?多加点班会死吗?总扯一些理念干嘛?对你没收益的事,你干嘛?”

    因为这样的分工模式,导致这种矛盾在工作中很多,而且似乎并没有更好的方法彻底解决。

    有人说,要解决很简单,要么强压,要么加大投入,下下狠心就得了。

    先来说说强压,似乎能够在短时间内达到目的,但纯属 “杀敌一千自损八百” 的招数,难道要业务研发团队停下手上的活,倾巢而出一起搞技术改造吗?更何况,前台承受的压力,是中后台团队无法想象的。

    退一步说,抛开 “互相理解” 这个话题,强压的套路等同于 “攻城为上,攻心为下”,对今后的管理与团队氛围都会带来诸多的麻烦。

    再来说说加大投入,看看我上面提到的 “死在路上的软件公司们”,还想加大中后台的投入吗?

    如果你不是大厂,还是算了吧。

    那句话怎么说来着?最悲惨的结局是,你的技术中后台越发强大,但你的业务规模却在逐渐萎缩。

    可悲,可叹。

    总结

    在互联网时代,技术圈似乎从来不缺少热议话题,但有质量,有深度,且能解决实际问题的却少之又少。

    现在人人都在讨论「中台」,今天「产品中台」,明天「数据中台」,这个说能提高效率,那个说能排除万难,聊得不亦乐乎。

    对于企业来说,话题热不热并不重点,方案牛不牛逼也不重要,关键是能帮助用户找到效率、质量与成本的平衡点,或许才算是一个合格的「技术中台」。

    展开全文
  • 导读:中台的存在价值是为它的客户服务,比如业务台和数据中台要快速响应前台应用的需求。 但如果中台同时服务于多个前台应用,在资源有限的情况下,必然涉及对来自不同应用的需求的优先级排序和取舍。如果前台...

    640?wx_fmt=gif

    导读:中台的存在价值是为它的客户服务,比如业务中台和数据中台要快速响应前台应用的需求。

     

    但如果中台同时服务于多个前台应用,在资源有限的情况下,必然涉及对来自不同应用的需求的优先级排序和取舍。如果前台应用急需某一能力,但中台又不能及时提供,是否允许前台先实现,等中台有时间再来沉淀?

     

    由此可以看出,大中台立足于横向的、全局的长远考虑,而小前台则注重于解决纵向的业务应用的当前问题。大中台的发展必然涉及权衡,但如何做取舍没有标准答案,需要结合实际情况进行。

     

    作者:陈新宇 罗家鹰 邓通 江威

    来源:大数据DT(ID:bigdatadt)

     

    640?wx_fmt=jpeg

     

     

    01 中台的演变

     

    中台的催生基石是能力共享。如果中台所提供的能力无法被共享,那就不是中台能力。如果中台只服务于一个前端应用,那就不是中台。

     

    那么哪些能力比较通用且是多个前台系统的共性需求?要回答这个问题,可从系统的组成开始分析,如图3-9所示。一个应用系统首先是为用户服务的,因此最先离不开的是系统的角色和用户。

     

    因此,建设中台的一个起步点就是先将角色和用户这些资源管理起来,形成用户共享中心。统一用户、统一权限、统一登录,可以看作是中台的雏形,但如果仅仅停留在此阶段,就退化成了单点登录。在此基础上,再发展与人相关的会员系统,比如会员的积分、积分的变动、会员的等级等就形成了会员中心。

     

    再者,用户是通过商品、订单与系统进行交互的,因此,商品的管理、订单的集中处理也是可以一起共享的。这些资源的统一集中管理后,相关的用户、会员、积分、订单等数据被存储在一起,方便全局管控。进行集中管理的资源越多,建设中台所取得的成果就会越大,就越能体现中台对前台应用的支撑作用。

     

    640?wx_fmt=png

    ▲图3-9 中台建设的三个步骤

     

    在资源集中管理的基础上,更重要的是抽象出系统能力。抽象是指在考虑目标事物时,去除表象的、次要的方面,而抽取相同的、主要的方面,从而做到从个别中把握一般规律。通俗一些的说法就是将目标事物模型化。只有通过抽象,设计出来的能力才能应用到类似的需求中。

     

    中台是为前台业务服务的,因此当前台业务有所更改时,中台要随需而变。这就要求中台具有很好的灵活性来支撑业务的开拓和发展:

     

    1. 数据模型需要根据前台业务要求实现可扩展性。

    2. 业务流程可根据场景和需求重新定义和编排,并可通过插件机制进行定制。

    3. 中台环境需要支持多环境可部署。比如不同的基础设施环境,包括公有云、私有云及容器云等;再比如不同的微服务框架,如阿里云的EDAS、开源的SpringCloud、Dubbo等。

     

    中台的建设不是从零起步,但是中台是为业务服务的,是需要根据企业业务演进逐渐积累而成的。因此中台的建设不是一蹴而就的。

     

     

    02 中台生态的形成

     

    中台是企业级共享能力平台,因此除了最开始提出的业务中台和数据中台,还会逐步发展出技术中台、研发中台、移动中台、AI中台、算法中台、组织中台等其他中台。

     

    1. 技术中台

     

    技术中台整合和包装了云基础设施,以及在其上建设的各种技术中间件,比如微服务、分布式缓存、消息队列、搜索引擎、分布式数据库等,并在此基础上建设和封装了简单易用的能力接口,如图3-10所示。

     

    640?wx_fmt=png

    ▲图3-10 技术中台

     

    技术中台的建设标准是参考在一个只提供虚拟机或容器的私有云上,建设一个业务中台或数据中台所需但私有云没有提供的技术相关组件。

     

    技术中台作为工具和组件,为建设前台应用和业务中台提供了基础设施重用的能力,大大缩短了它们的建设周期。如果数字中台(即业务中台+数据中台)是强大的中台炮火群,则技术中台提供的是如何根据需要快速搭建中台炮火阵地(即创建和部署不同环境下的中台)。

     

    如何让阵地建设得更加可靠、简捷易用(通过技术中台提供资源的动态扩展能力等)?隔离数字中台对基础设施的依赖。比如业务中台的每个业务服务中心都需要关系型数据库

     

    关系型数据库要提供一主一备和自动切换功能,以及读写分离和只读库创建的能力。为了快速访问大数据量的表,一般需要使用分布式数据库对其进行分库分表操作。

     

    分布式缓存是提高访问效率的一个必不可少的组件。通过消息队列实现异步解耦和大流量削峰填谷,这大大增强了前台应用应对大用户并发的能力。使用CDN加速的对象存储,可极大提高前端访问的性能。

     

    数字中台是在技术中台的基础上开发、运行的,但又不能与技术中台绑定。因为数字中台关心的是如何满足业务要求,而技术中台提供基础设施底层的能力,两者相互促进但又相互隔离。

     

    2. 研发中台

     

    研发中台是关注应用开发效率的管理平台,如图3-11所示。软件开发和系统建设是一项工程,涉及项目管理、团队协作、流程、测试、部署、运营、监控等方面。

     

    640?wx_fmt=png

    ▲图3-11 研发中台

     

    如何将在企业应用开发过程中的最佳实践沉淀为可重用的能力,从而更好地快速迭代开发创新型的应用,也是很多企业目前的一个关注点。这个关注点也是企业能力的体现,即研发中台。

     

    研发中台为应用开发提供了流程和持续交付的能力,包括敏捷开发管理、开发流水线、部署流水线、持续交付。敏捷管理一般由问题、迭代、实施等组成,并管理研发人员的日常工作和任务。

     

    开发流水线则涉及源代码的版本管理、分支的创建、合并和提交,半成品的构建、存储和使用以及产成品的构建。将产成品部署到指定环境并上线运行是部署流水线的职责。

     

    线上的应用需要监控,包括基础设施监控、应用监控、日志洞察、浏览器监控、链路分析和追踪等功能。研发中台为应用的开发提供了流程、质量管控和持续交付的能力。

     

    3. 移动中台

     

    消费者接触得最多的企业前台触点在移动端。如何保障移动端的迭代效率和稳定性也是企业需要着重考虑的。一个电商业务一开始可能只是一个工具型的App,完成对商品全生命周期的闭环支持。随着在业务中台基础上发展出相似业务,需要平台级的移动端开发支持。继续深化发展可能还需要支持多业态。

     

    因此为快速开发移动App、H5和小程序以支撑前台业务发展所进行的最佳实践就逐渐沉淀为移动中台,如图3-12所示。

     

    640?wx_fmt=png

    ▲图3-12 移动中台

     

    1. 移动App与其他前端技术比较,有其特殊性。比如移动App作为一个C/S架构,其发版模式需要通用应用市场的审核,而其客户端的更新是使用者控制的,提供远程配置、动态更新有助于控制App端。

    2. 移动业务是在线业务,对网络存在强依赖,而移动链路本身的稳定性和连通率等相比有线网络有一定的不足,因此消息推送的实现需要考虑网络因素。

    3. 因移动端质量相关问题,需要提供热修复等功能。

    4. 对移动App本身的安全扫描和加固也是一个需要着重考虑的因素。由于前端有不同的实现技术,如果完全使用不同的开发方式,对于企业来说是重复投入,且资源和技术不能共享。因此,使用Hybrid混合开发的方式,既可以支持移动App,又可以支持H5,甚至小程序,这也是移动中台需要研究的一部分。因此,尽可能将前端组件化,比如UI组件和图表组件,在此之上组装成业务组件,能大大提高移动端开发效率和质量。

     

    4. AI中台及其他

     

    前面所提的业务中台、数据中台等都是从技术系统层面展开的中台演变。企业在进行中台建设时,容易着手的也是对技术体系的改进。但要发挥中台的能力,让中台战略实际落地到企业,并为企业的业务目标服务,需要有与中台技术架构相匹配的组织架构。

     

    从Supercell 的“部落”,比如阿里巴巴的共享业务事业部、数据平台事业部,京东的前、中、后台,大家都可以看到建设中台需要两手抓,两条路线相匹配,齐头并进。

     

    如果将业务中台、数据中台等称为“战斗部队”,那么为企业提供的项目投资管理、风险管理、资源调度等的组织中台则是“战场指挥部”,指挥前线,调度后方。

     

    “大中台,小前台”这种组织形式,并不是什么新鲜事物,实际上它是一种理想化的支撑模式。前台业务足够灵活,配套支撑足够快捷,资源还能够高效复用。

     

    不过要让中台模式在企业中发挥作用,对企业本身也是有一定要求的,比如企业有一定规模,业务比较丰富,值得去提炼共性元素形成共享能力。如果同时开展多种相类似的业务,那么从业务A提炼出来的能力可能提供给业务B使用;或者虽然业务单一,但同一业务在不同地域有不同的模式,也能沉淀出很多共享能力。

     

    数据中台提供了数据分析报表来响应运营,并在此基础上提供数据能力直接服务于业务。那能不能更进一步,提供诸如个性化服务等与智能相关的能力?答案是肯定的,通过AI中台就可实现。

     

    AI中台借助数据中台的能力,尝试解决模型的训练、发布,智能服务的构建自动化,统一的元数据管理体系,模型的全生命周期管理等问题,通过AI能力平台化,降低对人员能力的要求。

     

    与数据中台利用CPU级别的资源不同,AI中台需要扩展对GPU资源管理和整合能力,为算法模型的开发者、训练者、标注管理者、数据管理者等构建智能服务的人员服务,并最终为业务人员提供智能化的服务。

     

     

    03 中台与前台的博弈

     

    中台通过提供基础服务和解决方案为前台业务应用提供服务。中台的职责是不断提升整体平台的服务能力基线。根据中台对前台业务的支持与参与度不同(见图3-13),会产生不同的中台建设路径。

     

    640?wx_fmt=png

    ▲图3-13 中台对业务的参与度

     

    一个极端理解是中台是工具,即将中台作为工具平台来建设。由于工具的通用能力强,抽象层度高,所以工具可适应各行各业的企业。如此,中台的研发人员可只专注技术相关的问题,而无须关注和了解企业本身的业务。

     

    但是正由于工具无法深入业务场景,也不内含业务能力,导致中台不能沉淀业务,从而使中台开发人员与业务方沟通不顺畅,中台方无法直接为业务赋能。为了解这个问题,需要一个长期的业务理解和系统建设过程。

     

    另一极端是中台完全为业务服务。中台方能快速理解业务需求,参与业务方的数据模型讨论、流程设计等,并将其变成系统实现。中台研发人员参与业务建设,符合中台为业务服务的目的,而且中台的能力也是通过业务沉淀下来的。

     

    但是过分关注业务,过分与业务团队耦合,会受限于时间和团队的能力,不仅中台可能会没有考虑通用的业务能力,也会导致无法更专注于对中台技术的深入研究。

     

    中台如果不从抽象度、适配性等角度出发,投入建设机制性的工作,很有可能局限于某单一业务,导致中台无法很好地适应其他相关业务的要求,从而不能很好地应对业务的变化。

     

    目前很多宣传中描述的数据中台走到了图3-13所示的最左侧:把数据建设的工具称为数据中台,或把数据治理、数据建模等工具宣称为数据中台(其实只是片面地在理解数据中台)。中台最主要的能力是提供业务方可重复使用的并与业务相关的能力。数据工具的能力太泛化,会导致与业务方的距离太远,从而不能很好地为业务方赋能。

     

    从历史发展来看,一开始企业建设了一个前台应用A(如图3-14所示)。随着业务的发展,扩展到类似的业务,由于业务快速发展的需要,很有可能重新开发另一个前台应用B。但随着应用B的建设,发现应用A和应用B的很多功能和能力是重复或相似的,因此考虑是不是可以通过建设公共的部分,避免重复投入和建设。由不同前台应用抽取出来的公共部分即为中台。

     

    640?wx_fmt=png

    ▲图3-14 中台与前台应用的关系

     

    但是中台建设是一个新的命题,需要更强有力的团队,需要不断探索。如果中台研发团队的研发能力和时间进度无法跟上前台业务的需求变化,那么中台就只能满足部分前台业务的需求。

     

    再者,如果中台的抽象程度低、扩展性差,则会导致中台无法满足前台业务需求。这时前台应用又因为业务本身的发展目标和压力不得不自行组织团队完成这部分功能,由此可能发生本应由中台提供的能力却最终实现在业务应用中。中台越做越小,前台应用越做越大。这样一来,进一步压缩了中台的生存空间。

     

    因此,中台既需要满足业务的需求,但又不能过度参与业务。中台能力的建设首先要保证投入到中台的资源不能成为业务建设的瓶颈。中台提供的能力要具有灵活性和可定制性,便于业务方根据规范自主完成,减少沟通成本,提升效率。

     

    “大中台,小前台”,并不意味着前台不重要。相反,建设大中台就是为了更好地服务于小前台。大中台要想发挥作用,体现出自己的价值,必须通过小前台的引导。因此,判断中台建设是否成功的指标应包括:前台有没有使用中台,前台从使用中台中获得了哪些好处,中台好不好用,愿不愿意继续使用中台。

     

     

    04 中台的进化策略

     

    虽然中台概念的提出到现在仅几年时间,但中台已经在这几年中走出了自己的路径。根据中台的进化和演变的历史及可能的方向,目前可以看到共有广度深度两种途径,如图3-15所示。

     

    640?wx_fmt=png

    ▲图3-15 中台的广度和深度两种进化策略

     

    广度是指中台所涉及的内容会越来越多,即可以认为各种中台的不断出现,也可以认为是一个中台内部的共享服务中心会不断横向扩展,从一开始所提的业务中台、数据中台,逐步演化到AI中台、技术中台、研发中台等。

     

    另一方面,一个中台范围内的共享能力也在扩展,从用户中心、交易中心、营销中心等扩展到内容中心、工单中心、成长中心等。中台团队如发现某一前台业务模式很好,则将其沉淀为共享服务,从而提供更多的业务,这也是在建设和加强中台。

     

    由于中台作为中枢点同时支撑多个前台业务,因此中台成为打通前台业务的最好着力点,让不同的前台业务可以互相借力和引流,互相促进发展。

     

    中台所沉淀的共享服务能力并不要求支撑所有前台业务,只要有多于一个前台业务需要某一种能力,此能力即可沉淀为中台能力,因此我们不能大而全地建设中台。

     

    如果企业认为现在企业各系统的用户管理能力需要统一,那就可以着手进行用户中心的建设。在此基础上,如果企业发现会员需要统一管理,订单需要全局视图,那么就构建会员中心和订单中心。因此,中台的建设是可以分阶段逐步实施的,无须将所有重构全部一起推动,而后者既会增加复杂性,又会提高风险,还不能及时得到反馈。

     

    中台的成长离不开前台业务的创新。只有不断进行业务迭代和更新试错,对中台提出新的挑战和沉淀,才会让中台做得更好。另一方面,中台团队也需要有自己的产品化、平台化建设思考,并作为新业务的孵化器。

     

    中台还需要建设成为开放的体系。开放不仅仅是对企业内部开放,也要对企业外部开放。通过中台建设,企业可以将自有的系统变为开放式平台,从而为其他企业充分提供第三方的数据和服务。再者,中台本身通过开放也可以充分利用其他第三方数据和服务。开放可以接口的方式,通过开放API,开创新的商业机会和应用模式。

     

    中台的开放也意味着中台需要支持个性化需求。通过抽象能沉淀共性的流程、数据模型等。但不同业务总有不同点,这些不同的需求就需要个性化的支撑。中台和前台一般是由不同团队负责的。因此为了提高效率,中台必须留出足够灵活的扩展点,以便不同前台业务根据其需求进行定制化扩展。

     

    中台作为平台,必然需要考虑拆分整体应用形成业务组件,通过业务抽象建模,解决共性的问题,从而更好地为业务服务。对业务问题的抽象程度越高,中台对业务的适配度就越高,需要对具体业务参与度就越低,从而更能发挥中台及中台团队的价值。因为越好的抽象越能发挥业务应用开发的创造性。

     

    在考虑拆分的同时,必须设计整体框架和组装策略,即组件间的协作机制。通过协作机制,才能让各业务组件协同实现业务场景以达到业务目标。

     

    中台作为一个平台,其本身的运营也需要数据支撑。比如需要统计和观察中台以API形式提供的共享能力,从而了解中台哪些能力被业务引用及引用的频率,所使用的参数模式等;哪些设计的接口能力没有用处等。有了实际的数据,可更好地迭代中台。

     

    关于作者:陈新宇,云徙科技联合创始人兼首席架构师,中国软件行业协会应用软件产品云服务分会“数字企业中台应用专家顾问团”副主任,领导云徙科技数字中台系统的规划、建设并赋能企业落地实施。

    罗家鹰,云徙科技副总裁,拥有20年企业IT咨询及服务经验,近三年一直致力于阿里生态企业中台赋能数字商业的实践与布道,曾先后为房地产、酒水、日化、医药、农牧、物流等行业数十家头部企业提供中台化数字化转型咨询服务。

    邓通,云徙科技汽车事业部总经理,先后主导过长安汽车、一汽集团、长安福特等头部车企以及博郡汽车、爱驰汽车等新能源车企基于汽车行业中台的数字化营销项目。

    江威,云徙科技地产事业部总经理,领导中台在地产方面的建设与落地,长期从事阿里中台赋能地产行业的研究与布道,拥有丰富的地产项目实施经验。

     

    延伸阅读《中台战略:中台建设与数字商业》

    点击上图了解及购买

    转载请联系微信:DoctorData

     

    推荐语:双中台技术领先企业阿里系云徙科技官方出品,从成功要素、建设方法论、架构设计、成熟度模型4个维度详解业务中台、数据中台建设思路和方法,实现企业数字化转型。

     

    640?

     

    「大数据」内容合伙人之「鉴书小分队」上线啦!

     

    最近,你都在读什么书?有哪些心得体会想要跟大家分享?

     

    数据叔最近搞了个大事——联合优质图书出版商机械工业出版社华章公司发起鉴书活动。

     

    简单说就是:你可以免费读新书,你可以免费读新书的同时,顺手码一篇读书笔记就行。详情请在大数据公众号后台对话框回复合伙人查看。

     

    640?

     

    有话要说?

     

    Q: 你希望中台都能解决哪些问题?

    欢迎留言与大家分享

     

    猜你想看?

     

    •  

    •  

    •  

    •  

     

    更多精彩?

     

    在公众号对话框输入以下关键词

    查看更多优质内容!

     

    PPT | 报告 | 读书 | 书单 | 干货 

    大数据 | 揭秘 | Python | 可视化

    AI | 人工智能 | 5G | 区块链

    机器学习 | 深度学习 | 神经网络

    合伙人 1024 | 段子 | 数学 | 高考

     

    据统计,99%的大咖都完成了这个神操作

    ?

     

    640?wx_fmt=png

     

    觉得不错,请把这篇文章分享给你的朋友

    转载 / 投稿请联系:baiyu@hzbook.com

    更多精彩,请在后台点击“历史文章”查看

    640?wx_fmt=gif点击阅读原文,了解更多

    展开全文
  • 数据中台是一个公司级的平台系统,所以不能只从技术层面去设计,还要考虑包括流程、标准化等在内的顶层设计。 2、从中间件工具到平台介绍宜信是如何设计建设敏捷数据中台的。 3、结合典型案例介绍宜信敏捷数据中台...
  • 文/技术领导力社区编辑/Emma阿里中间件高级技术专家 钟华、高级技术专家 泠茗、中间件技术专家 玄难,在公开分享和访谈提到阿里技术中台建设实践,包括:技术中台、移动...
  • 宜信敏捷数据中台建设实践,宜信于2017年推出了一系列大数据开源工具,包括大家熟悉的DBus、Wormhole、Moonbox、Davinci等,在技术社区内得到了广泛关注和好评。那么这些工具是如何在宜信内部应用的?它们和宜信数据...
  • 中台建设之路(一)

    千次阅读 2020-01-05 17:14:50
    现如今各种中台层出不群,如技术中台、业务中台、数据中台、安全中台、算法中台、移动中台、AI中台、研发中台、组织中台等,我们撇开这些概念,回归到中台的本质,中台的本质是什么,本质是能力复用平台或者企业级...
  • 台战略:中台建设与数字商业

    千次阅读 2019-12-27 15:24:54
    1.5 中台驱动企业数字化转型 第2章 云智慧时代的数字营销 2.1 数字营销的背景 2.2 数字营销的定义 2.3 全球数字营销的3个重要趋势 2.4 中国数字营销的5个新特性 2.5 数字营销解决方案架构分析 2.6 面...
  • 内容来源:宜信技术学院第2期技术沙龙-线上直播|宜信敏捷数据中台建设实践 分享嘉宾:宜信数据台平台团队负责人 卢山巍 导读:宜信于2017年推出了一系列大数据开源工具,包括大家熟悉的DBus、Wormhole、Moonbox、...
  • 大型企业业务中台建设思考

    千次阅读 2020-05-20 09:44:52
    只需要通过简单的集成就能使用,对于将来的IT技术发展我估计也是这样的发展方向,IT技术会逐步下沉到更底层,对外输出的仅仅是傻瓜化的工具,让非专业的业务人员参与到IT建设中来,甚至是系统功能的创造者。...
  • 中台的理解分析与建设

    千次阅读 2020-11-18 18:17:15
    业务中台、数据中台、业务中台
  • 企业中台建设思路,1.1 当前问题 1. 系统维护困难 2. 二次开发迭代仅原厂商可以进行 3. 新承建系统过多重复工作 4. 同一业主下不同系统存在数据壁垒
  • 企业台的战略价值和案例分享;技术与应用发展研讨会;企业IT架构转型之道阿里巴巴台战略思想与架构实战;安徽XX企业级智能中台建设规划汇报;业务专题研究-互联网化营销下的渠道能力建设之聚焦技术
  • 业务中台、数据中台技术中台到底是什么?00 中台能力总体框架01 业务中台02 数据中台数据应用技术发展迅猛数据架构更加灵活数据来源更加多元化,数据格式更加多样化数据智能化应用将会越来越广泛03 技术中台1. API...
  • 阿里巴巴台战略最早从业务台和数据中台建设开始,采用了双台的建设模式,到后来发展出了移动台、技术中台和研发台等,这些台的能力综合在一起就构成了阿里巴巴企业级数字化能力。传统企业在技术能力、...
  • 阿里数据中台建设过程、方法论、主要核心的产品、技术架构等等,对技术圈来说一直非常神秘。并且,阿里已经将中台建设方法论形成了解决方案,向行业输出,这也导致了阿里台相关资料...
  • 互联网技术中台

    千次阅读 2019-09-09 22:06:54
    在有些人眼里:中台就是技术平台,像微服务开发框架、Devops平台、PaaS平台,容器云之类的,人们都叫它“技术中台”。 在有些人眼里:中台就是微服务业务平台,像最常见的什么用户中心,订单中心,各种微服务集散地...
  • 数据台可以说是当下非常火热的话题,在BATJ等互联网大厂大肆推广中台建设成果的当下,各个行业的企业似乎都想做数字化转型,建设业务台,但是台到底是啥,需要我们提前了解和学习,本文是我学习张旭老师《数据...
  • 关于数据中台的概念定义,业内有各种各样的版本,尤其是涉及数据中台与数据仓库、数据平台等相关概念的差异一直争议不断,可谓一百个人眼中,就有一百个数据中台,千百万人眼中,就有千百万个数据中台。关于概念之...
  • 从业务到中台,必须经历抽象建模的过程。这个过程分为两个阶段,分别是 0 级抽象中心建模的阶段和 1 级抽象组件建模的阶段。每个阶段采用的建模抽象机制都是实体抽象法。下面以 0 级阶段建模...
  • 中台战略 技术中台

    千次阅读 2018-12-12 16:03:00
    5、企业中台:重点关注业务中台的这几个点,其他的请亲自阅读原书--服务是最不需要稳定的,服务需要不断的业务滋养;共享服务体系是培育业务创新的土壤,能够赋予业务快速创新和试错能力;改变组织阵型会带来组织...
  • 中台打破了应用系统的壁垒,从企业全局梳理和规划业务程,重构了组织架构、业务架构与IT 架构。 在梳理了企业的IT 现状并回顾了SOA 的历史之后,我们需要对中台架构进行一番详细的介绍,阿里巴巴的Aliware 团队曾经...
  • 业务中台技术方案统一技术架构、统一应用运行运维平台,基于华为云DevOps一站式开发运维平台和中间件快速开发和减少运维。 一个大平台,四个标准化(基础设施、应用架构、数据集成、交付过程) 底层核心竞争力:以...
  • 早在今年四月份,便开始看《大数据之路:阿里巴巴大数据实践》一书,再迅速过了邓中华老师这本《大数据大创新:阿里巴巴云上数据中台之道》,基本上可以窥见阿里数据中台建设过程以及一些技术细节。其中宗华作为一...
  • 19下半年开始业务台的建设成为热点,网上各种文章介绍业务台的建设的经验和教训,有吹捧的,把业务台视为企业数字化转型的救命稻草,有黑的,通过一些失败的案例,把业务中台建设视为企业数字化转型的毒药。...
  • 这是“技术领导力”的第210期分享编辑/Emma阿里研究员--玄难,曾在《从应用到中台--业务平台的演进》的分享提到,阿里台化主要解决4个问题:1、信息获取成本高2、...
  • 文/技术领导力社区编辑/Emma技术领导力社区,中台组,耗费16小时,从300多篇中台架构资料,甄选出50篇优质文章,内容包括7大类:阿里专家谈中台、行业专家解读中台、...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 90,605
精华内容 36,242
关键字:

技术中台建设