精华内容
下载资源
问答
  • 技术中台
    千次阅读
    2021-07-04 19:06:12

    前言

    2015年阿里巴巴提出“大中台,小前台”的中台战略,通过实施中台战略找到能够快速应对外界变化,整合阿里各种基础能力,高效支撑业务创新的机制。阿里巴巴中台战略最早从业务中台和数据中台建设开始,采用了双中台的建设模式,到后来发展出了移动中台、技术中台和研发中台等,这些中台的能力综合在一起就构成了阿里巴巴企业级数字化能力。传统企业在技术能力、组织架构和商业模式等方面与阿里巴巴存在非常大的差异,在实施中台战略时是否可以照搬阿里巴巴中台建设模式?传统企业中台数字化转型需要提升哪些方面的基本能力呢?下面我们一起来分析分析。

    00 中台能力总体框架

    中台建设过程从根本上讲是企业自身综合能力持续优化和提升的过程,最终目标是实现企业级业务能力复用和不同业务板块能力的联通和融合。

    企业级的综合能力,一般包含以下四种:业务能力、数据能力、技术能力和组织能力,如图2-1所示。

    img

    ▲图2-1 企业中台数字化转型基本能力框架

    业务能力主要体现为对中台领域模型的构建能力,对领域模型的持续演进能力,企业级业务能力的复用、融合和产品化运营能力,以及快速响应市场的商业模式创新能力。

    数据能力主要体现为企业级的数据融合能力、数据服务能力以及对商业模式创新和企业数字化运营的支撑能力。

    技术能力主要体现为对设备、网络等基础资源的自动化运维和管理能力,对微服务等分布式技术架构体系化的设计、开发和架构演进能力。

    组织能力主要体现为一体化的研发运营能力和敏捷的中台产品化运营能力,还体现为快速建设自适应的组织架构和中台建设方法体系等方面的能力。

    这些能力相辅相成,融合在一起为企业中台数字化转型发挥最大效能。接下来,我们一起来看看在不同的领域应该如何实现这些能力。

    01 业务中台

    企业所有能力建设都是服务于前台一线业务的。从这个角度来讲,所有中台应该都可以称为业务中台。但我们所说的业务中台一般是指支持企业线上核心业务的中台。

    业务中台承载了企业核心关键业务,是企业的核心业务能力,也是企业数字化转型的重点。业务中台的建设目标是:“将可复用的业务能力沉淀到业务中台,实现企业级业务能力复用和各业务板块之间的联通和协同,确保关键业务链路的稳定高效,提升业务创新效能。”

    业务中台的主要目标是实现企业级业务能力的复用,所以业务中台建设需优先解决业务能力重复建设和复用的问题。通过重构业务模型,将分散在不同渠道和业务场景(例如:互联网应用和传统核心应用)重复建设的业务能力,沉淀到企业级中台业务模型,面向企业所有业务场景和领域,实现能力复用和流程融合。

    图2-2是一个业务中台示例。在业务中台设计时,我们可以将用户管理、订单管理、商品管理和支付等这些通用的能力,通过业务领域边界划分和领域建模,沉淀到用户中心、订单中心、商品中心和支付中心等业务中台,然后基于分布式微服务技术体系完成微服务建设,形成企业级解决方案,面向前台应用提供可复用的业务能力。

    img

    image

    ▲图2-2 业务中台示例

    在技术实现上,中台的系统落地可以采用微服务架构。微服务是目前公认的业务中台技术最佳实现,可以有效提升业务扩展能力,实现业务能力复用。

    在业务建模上,中台领域建模可以采用领域驱动设计(DDD)方法,通过划分业务限界上下文边界,构建中台领域模型,根据领域模型完成微服务拆分和设计。

    业务中台可以面向前台应用提供基于API接口级的业务服务能力,也可以将领域模型所在的微服务和微前端组合为业务单元,以组件的形式面向前台应用,提供基于微前端的页面级服务能力。

    业务中台建设完成后,前台应用就可以联通和组装各个不同中台业务板块,既提供企业级一体化业务能力支撑,又可以提供灵活的场景化销售能力支撑。

    02 数据中台

    数据中台与业务中台相辅相成,共同支持前台一线业务。数据中台除了拥有传统数据平台的统计分析和决策支持功能外,会更多聚焦于为前台一线交易类业务提供智能化的数据服务,支持企业流程智能化、运营智能化和商业模式创新,实现“业务数据化和数据业务化”。

    最近几年,数据应用领域出现了很多新的趋势。数据中台建设模式也随着这些趋势在发生变化,主要体现在以下几点。

    第一,数据应用技术发展迅猛。近几年涌现出了大量新的数据应用技术,如NoSQL、NewSQL和分布式数据库等,以及与数据采集、数据存储、数据建模和数据挖掘等大数据相关的技术。这些技术解决业务问题的能力越来越强,但同时也增加了技术实现的复杂度。

    第二,数据架构更加灵活。在从单体向微服务架构转型后,企业业务和数据形态也发生了很大的变化,数据架构已经从集中式架构向分布式架构转变。

    第三,数据来源更加多元化,数据格式更加多样化。随着车联网、物联网、LBS和社交媒体等数据的引入,数据来源已从单一的业务数据向复杂的多源数据转变,数据格式也已经从以结构化为主向结构化与非结构化多种模式混合的方向转变。

    第四,数据智能化应用将会越来越广泛。在数字新基建的大背景下,未来企业将汇集多种模式下的数据,借助深度学习和人工智能等智能技术,优化业务流程,实现业务流程的智能化,通过用户行为分析提升用户体验,实现精准营销、反欺诈和风险管控,实现数字化和智能化的产品运营以及AIOps等,提升企业数字智能化水平。

    面对复杂的数据领域,如何建设数据中台管理并利用好这些数据?

    这对企业来说是一个非常重要的课题。

    数据中台的大部分数据来源于业务中台,经过数据建模和数据分析等操作后,将加工后的数据,返回业务中台为前台应用提供数据服务,或直接以数据类应用的方式面向前台应用提供API数据服务。

    数据中台一般包括数据采集、数据集成、数据治理、数据应用和数据资产管理,另外还有诸如数据标准和指标建设,以及数据仓库或大数据等技术应用。图2-3是2017年阿里云栖大会上的一个数据中台示例。

    img

    ▲图2-3 数据中台示例(图参考:2017年阿里云栖大会)

    综上所述,数据中台建设需要做好以下三方面的工作。

    一是建立统一的企业级数据标准指标体系,解决数据来源多元化和标准不统一的问题。企业在统一的数据标准下,规范有序地完成数据采集、数据建模、数据分析、数据集成、数据应用和数据资产管理。

    二是建立与企业能力相适应的数据研发、分析、应用和资产管理技术体系。结合企业自身技术能力和数据应用场景,选择合适的技术体系构建数据中台。

    三是构建支持前台一线业务的数据中台。业务中台微服务化后,虽然提升了应用的高可用能力,但是随着数据和应用的拆分,会形成更多的数据孤岛,会增加应用和数据集成的难度。在业务中台建设的同时,需要同步启动数据中台建设,整合业务中台数据,消除不同业务板块核心业务链条之间的数据孤岛,对外提供统一的一致的数据服务。用“业务+数据”双中台模式,支持业务、数据和流程的融合。

    数据中台投入相对较大,收益周期较长,但会给企业带来巨大的潜在商业价值,也是企业未来数字化运营的重要基础。企业可以根据业务发展需求,制定好阶段性目标,分步骤、有计划地整合好现有数据平台,演进式推进数据中台建设。

    03 技术中台

    业务中台落地时需要有很多的技术组件支撑,这些不同技术领域的技术组件就组成了技术中台。业务中台大多采用微服务架构,以保障系统高可用性,有效应对高频海量业务访问场景,所以技术中台会有比较多的微服务相关的技术组件。

    一般来说,技术中台会有以下几类关键技术领域的组件,如API网关、前端开发框架、微服务开发框架、微服务治理组件、分布式数据库以及分布式架构下诸如复制、同步等数据处理相关的关键技术组件,如图2-4所示。

    1. API网关

    微服务架构一般采用前后端分离设计,前端页面逻辑和后端微服务业务逻辑独立开发、独立部署,通过网关实现前后端集成。

    前台应用接入中台微服务的技术组件一般是API网关。

    API网关主要包括:鉴权、降级限流、流量分析、负载均衡、服务路由和访问日志等功能。API网关可以帮助用户,方便地管理微服务API接口,实现安全的前后端分离,实现高效的系统集成和精细的服务监控。

    2. 开发框架

    开发框架主要包括前端开发框架和后端微服务开发框架。基于前、后端开发框架,分别完成前端页面逻辑和后端业务逻辑的开发。

    前端开发框架主要是面向PC端或者移动端应用,用于构建系统表示层,规范前后端交互,降低前端开发成本。

    img

    ▲图2-4 技术中台关键技术领域

    微服务开发框架用于构建企业级微服务应用。一般具备自动化配置、快速开发、方便调试及部署等特性,提供微服务注册、发现、通信、容错和监控等服务治理基础类库,帮助开发人员快速构建产品级的微服务应用。

    开发框架一般都支持代码自动生成、本地调试和依赖管理等功能。

    3. 微服务治理

    微服务治理是在微服务的运行过程中,针对微服务的运行状况采取的动态治理策略,如服务注册、发现、限流、熔断和降级等,以保障微服务能够持续稳定运行。

    微服务治理主要应用于微服务运行中的状态监控、微服务运行异常时的治理策略配置等场景,保障微服务在常见异常场景下的自恢复能力。

    微服务治理技术组件一般包括服务注册、服务发现、服务通信、配置中心、服务熔断、容错和微服务监控等组件。

    常见的微服务治理有Dubbo、Spring Cloud和Service Mesh等技术体系。

    4. 分布式数据库

    分布式数据库一般都具有较强的数据线性扩展能力,它们大多采用数据多副本机制实现数据库高可用,具有可扩展和低成本等技术优势。

    分布式数据库一般包括三类:交易型分布式数据库、分析型分布式数据库和交易分析混合型分布式数据库。

    交易型分布式数据库用于解决交易型业务的数据库计算能力,它支持数据分库、分片、数据多副本,具有高可用的特性,提供统一的运维界面,具备高性能的交易型业务数据处理能力。主要应用于具有跨区域部署和高可用需求,需支持高并发和高频访问的核心交易类业务场景。

    分析型分布式数据库通过横向扩展能力和并行计算能力,提升数据整体计算能力和吞吐量,支持海量数据的分析。主要应用于大规模结构化数据的统计分析、高性能交互式分析等场景,如数据仓库、数据集市等。

    交易分析混合型分布式数据库通过资源隔离、分时和数据多副本等技术手段,基于不同的数据存储、访问性能和容量等需求,使用不同的存储介质和分布式计算引擎,同时满足业务交易和分析需求。主要应用于数据规模大和访问并发量大,需要解决交易型数据同步到分析型数据库时成本高的问题,需要解决数据库入口统一的问题,需要支持高可用和高扩展性等数据处理业务场景。

    5. 数据处理组件

    为了提高应用性能和业务承载能力,降低微服务的耦合度,实现分布式架构下的分布式事务等要求,技术中台还有很多数据处理相关的基础技术组件。如:分布式缓存、搜索引擎、数据复制、消息中间件和分布式事务等技术组件。

    分布式缓存是将高频热点数据集分布于多个内存集群节点,以复制、分发、分区和失效相结合的方式进行维护,解决高并发热点数据访问性能问题,降低后台数据库访问压力,提升系统吞吐能力。典型的开源分布式缓存技术组件有Redis。

    搜索引擎主要解决大数据量的快速搜索和分析等需求。将业务、日志类等不同类型的数据,加载到搜索引擎,提供可扩展和近实时的搜索能力。

    数据复制主要解决数据同步需求,实现同构、异构数据库间以及跨数据中心的数据复制,满足数据多级存储、交换和整合需求。主要应用于基于表或库的业务数据迁移、业务数据向数据仓库复制等数据迁移场景。数据复制技术组件大多采用数据库日志捕获和解析技术,在技术选型时需考虑数据复制技术组件与源端数据库的适配能力。

    消息中间件主要适用于数据最终一致性的业务场景,它采用异步化的设计,实现数据同步转异步操作,支持海量异步数据调用,并通过削峰填谷设计提高业务吞吐量和承载能力。它被广泛用于微服务之间的数据异步传输、大数据日志采集和流计算等场景。另外,在领域驱动设计的领域事件驱动模型中,消息中间件是实现领域事件数据最终一致性的非常关键的技术组件,可以实现微服务之间的解耦,满足“高内聚,松耦合”设计原则。典型的开源消息中间件有Kafka等。

    分布式事务主要是解决分布式架构下事务一致性的问题。单体应用被拆分成微服务后,原来单体应用大量的内部调用会变成跨微服务访问,业务调用链路中任意一个节点出现问题,都可能造成数据不一致。分布式事务是基于分布式事务模型,保证跨数据库或跨微服务调用场景下的数据一致性。

    分布式事务虽然可以实时保证数据的一致性,但过多的分布式事务设计会导致系统性能下降。因此微服务设计时应优先采用基于消息中间件的最终数据一致性机制,尽量避免使用分布式事务。

    技术中台是业务中台建设的关键技术基础。在中台建设过程中,可以根据业务需要不断更新和吸纳新的技术组件,也可以考虑将一些不具有明显业务含义的通用组件(如认证等),通过抽象和标准化设计后纳入技术中台统一管理。为了保证业务中台的高性能和稳定性,在技术组件选型时一定要记住:尽可能选用成熟的技术组件。

    更多相关内容
  • 业务中台、数据中台技术中台到底是什么?

    千次阅读 多人点赞 2021-03-16 13:48:38
    业务中台、数据中台技术中台到底是什么?00 中台能力总体框架01 业务中台02 数据中台数据应用技术发展迅猛数据架构更加灵活数据来源更加多元化,数据格式更加多样化数据智能化应用将会越来越广泛03 技术中台1. API...

    作者:大数据DT
    来源:大数据DT

    导读:2015年 阿里巴巴提出“大中台,小前台”的中台战略,通过实施中台战略找到能够快速应对外界变化,整合阿里各种基础能力,高效支撑业务创新的机制。

    阿里巴巴中台战略最早从业务中台数据中台建设开始,采用了双中台的建设模式,

    到后来发展出了移动中台技术中台研发中台等,这些中台的能力综合在一起就构成了阿里巴巴企业级数字化能力。

    传统企业在技术能力、组织架构和商业模式等方面与阿里巴巴存在非常大的差异,在实施中台战略时是否可以照搬阿里巴巴中台建设模式?传统企业中台数字化转型需要提升哪些方面的基本能力呢?

    00 中台能力总体框架

    中台建设过程从根本上讲是企业自身综合能力持续优化和提升的过程,最终目标是实现企业级业务能力复用和不同业务板块能力的联通和融合。

    企业级的综合能力,一般包含以下四种:业务能力数据能力技术能力组织能力,如图2-1所示。
    在这里插入图片描述
    ▲图2-1 企业中台数字化转型基本能力框架


    • 业务能力:主要体现为对中台领域模型的构建能力,对领域模型的持续演进能力,企业级业务能力的复用、融合和产品化运营能力,以及快速响应市场的商业模式创新能力。

    • 数据能力:主要体现为企业级的数据融合能力、数据服务能力以及对商业模式创新和企业数字化运营的支撑能力。

    • 技术能力:主要体现为对设备、网络等基础资源的自动化运维和管理能力,对微服务等分布式技术架构体系化的设计、开发和架构演进能力。

    • 组织能力:主要体现为一体化的研发运营能力和敏捷的中台产品化运营能力,还体现为快速建设自适应的组织架构和中台建设方法体系等方面的能力。

    这些能力相辅相成,融合在一起为企业中台数字化转型发挥最大效能。接下来,我们一起来看看在不同的领域应该如何实现这些能力。

    01 业务中台

    企业所有能力建设都是服务于前台一线业务的。从这个角度来讲,所有中台应该都可以称为业务中台。但我们所说的业务中台一般是指支持企业线上核心业务的中台

    业务中台承载了企业核心关键业务,是企业的核心业务能力,也是企业数字化转型的重点。

    业务中台的建设目标是:“将可复用的业务能力沉淀到业务中台,实现企业级业务能力复用和各业务板块之间的联通和协同,确保关键业务链路的稳定高效,提升业务创新效能。

    业务中台的主要目标是实现企业级业务能力的复用,所以业务中台建设需优先解决业务能力重复建设和复用的问题。通过重构业务模型,将分散在不同渠道和业务场景(例如:互联网应用和传统核心应用)重复建设的业务能力,沉淀到企业级中台业务模型,面向企业所有业务场景和领域,实现能力复用和流程融合。

    图2-2是一个业务中台示例。在业务中台设计时,我们可以将用户管理、订单管理、商品管理和支付等这些通用的能力,通过业务领域边界划分和领域建模,沉淀到用户中心、订单中心、商品中心和支付中心等业务中台,然后基于分布式微服务技术体系完成微服务建设,形成企业级解决方案,面向前台应用提供可复用的业务能力。
    在这里插入图片描述
    ▲图2-2 业务中台示例


    在技术实现上,中台的系统落地可以采用微服务架构。微服务是目前公认的业务中台技术最佳实现,可以有效提升业务扩展能力,实现业务能力复用。

    在业务建模上,中台领域建模可以采用领域驱动设计(DDD)方法,通过划分业务限界上下文边界,构建中台领域模型,根据领域模型完成微服务拆分和设计。

    业务中台可以面向前台应用提供基于API接口级的业务服务能力,也可以将领域模型所在的微服务和微前端组合为业务单元,以组件的形式面向前台应用,提供基于微前端的页面级服务能力。

    业务中台建设完成后,前台应用就可以联通和组装各个不同中台业务板块,既提供企业级一体化业务能力支撑,又可以提供灵活的场景化销售能力支撑。

    02 数据中台

    数据中台与业务中台相辅相成,共同支持前台一线业务。

    数据中台除了拥有传统数据平台的统计分析和决策支持功能外,会更多聚焦于为前台一线交易类业务提供智能化的数据服务,支持企业流程智能化、运营智能化、商业模式创新,实现“业务数据化和数据业务化”。

    最近几年,数据应用领域出现了很多新的趋势。数据中台建设模式也随着这些趋势在发生变化,主要体现在以下几点。

    数据应用技术发展迅猛

    第一,数据应用技术发展迅猛。近几年涌现出了大量新的数据应用技术,如NoSQL、NewSQL和分布式数据库等,以及与数据采集、数据存储、数据建模和数据挖掘等大数据相关的技术。这些技术解决业务问题的能力越来越强,但同时也增加了技术实现的复杂度。

    数据架构更加灵活

    第二,数据架构更加灵活。在从单体向微服务架构转型后,企业业务和数据形态也发生了很大的变化,数据架构已经从集中式架构向分布式架构转变。

    数据来源更加多元化,数据格式更加多样化

    第三,数据来源更加多元化,数据格式更加多样化。随着车联网、物联网、LBS和社交媒体等数据的引入,数据来源已从单一的业务数据向复杂的多源数据转变,数据格式也已经从以结构化为主向结构化与非结构化多种模式混合的方向转变。

    数据智能化应用将会越来越广泛

    第四,数据智能化应用将会越来越广泛。在数字新基建的大背景下,未来企业将汇集多种模式下的数据,借助深度学习和人工智能等智能技术,优化业务流程,实现业务流程的智能化,通过用户行为分析提升用户体验,实现精准营销、反欺诈和风险管控,实现数字化和智能化的产品运营以及AIOps等,提升企业数字智能化水平。



    面对复杂的数据领域,如何建设数据中台管理并利用好这些数据?

    这对企业来说是一个非常重要的课题。

    数据中台的大部分数据来源于业务中台,经过数据建模和数据分析等操作后,将加工后的数据,返回业务中台为前台应用提供数据服务,或直接以数据类应用的方式面向前台应用提供API数据服务。

    数据中台一般包括数据采集、数据集成、数据治理、数据应用和数据资产管理,另外还有诸如数据标准和指标建设,以及数据仓库或大数据等技术应用。

    图2-3是2017年阿里云栖大会上的一个数据中台示例。
    在这里插入图片描述
    ▲图2-3 数据中台示例(图参考:2017年阿里云栖大会)


    综上所述,数据中台建设需要做好以下三方面的工作。

    • 一是建立统一的企业级数据标准指标体系,解决数据来源多元化和标准不统一的问题
      企业在统一的数据标准下,规范有序地完成数据采集、数据建模、数据分析、数据集成、数据应用和数据资产管理。

    • 二是建立与企业能力相适应的数据研发、分析、应用和资产管理技术体系
      结合企业自身技术能力和数据应用场景,选择合适的技术体系构建数据中台。

    • 三是构建支持前台一线业务的数据中台
      业务中台微服务化后,虽然提升了应用的高可用能力,但是随着数据和应用的拆分,会形成更多的数据孤岛,会增加应用和数据集成的难度。在业务中台建设的同时,需要同步启动数据中台建设,整合业务中台数据,消除不同业务板块核心业务链条之间的数据孤岛,对外提供统一的一致的数据服务。用“业务+数据”双中台模式,支持业务、数据和流程的融合。

    数据中台投入相对较大,收益周期较长,但会给企业带来巨大的潜在商业价值,也是企业未来数字化运营的重要基础。企业可以根据业务发展需求,制定好阶段性目标,分步骤、有计划地整合好现有数据平台,演进式推进数据中台建设。

    03 技术中台

    业务中台落地时需要有很多的技术组件支撑,这些不同技术领域的技术组件就组成了技术中台。

    业务中台大多采用微服务架构,以保障系统高可用性,有效应对高频海量业务访问场景,所以技术中台会有比较多的微服务相关的技术组件

    一般来说,技术中台会有以下几类关键技术领域的组件,如API网关、前端开发框架、微服务开发框架、微服务治理组件、分布式数据库以及分布式架构下诸如复制、同步等数据处理相关的关键技术组件,如图2-4所示。

    1. API网关

    微服务架构一般采用前后端分离设计,前端页面逻辑和后端微服务业务逻辑独立开发、独立部署,通过网关实现前后端集成。

    前台应用接入中台微服务的技术组件一般是API网关。

    API网关主要包括:鉴权、降级限流、流量分析、负载均衡、服务路由和访问日志等功能

    API网关可以帮助用户,方便地管理微服务API接口,实现安全的前后端分离,实现高效的系统集成和精细的服务监控。

    2. 开发框架

    开发框架主要包括前端开发框架和后端微服务开发框架。基于前、后端开发框架,分别完成前端页面逻辑和后端业务逻辑的开发。

    前端开发框架主要是面向PC端或者移动端应用,用于构建系统表示层,规范前后端交互,降低前端开发成本。
    在这里插入图片描述
    ▲图2-4 技术中台关键技术领域


    微服务开发框架用于构建企业级微服务应用。

    一般具备自动化配置、快速开发、方便调试及部署等特性,提供微服务注册、发现、通信、容错和监控等服务治理基础类库,帮助开发人员快速构建产品级的微服务应用。

    开发框架一般都支持代码自动生成、本地调试和依赖管理等功能

    3. 微服务治理

    微服务治理是在微服务的运行过程中,针对微服务的运行状况采取的动态治理策略,如服务注册、发现、限流、熔断和降级等,以保障微服务能够持续稳定运行

    微服务治理主要应用于微服务运行中的状态监控、微服务运行异常时的治理策略配置等场景,保障微服务在常见异常场景下的自恢复能力。

    微服务治理技术组件一般包括服务注册、服务发现、服务通信、配置中心、服务熔断、容错和微服务监控等组件。

    常见的微服务治理有Dubbo、Spring Cloud和Service Mesh等技术体系

    4. 分布式数据库

    分布式数据库一般都具有较强的数据线性扩展能力,它们大多采用数据多副本机制实现数据库高可用,具有可扩展和低成本等技术优势。

    分布式数据库一般包括三类:交易型分布式数据库分析型分布式数据库交易分析混合型分布式数据库

    • 交易型分布式数据库:用于解决交易型业务的数据库计算能力,它支持数据分库、分片、数据多副本,具有高可用的特性,提供统一的运维界面,具备高性能的交易型业务数据处理能力。主要应用于具有跨区域部署和高可用需求,需支持高并发和高频访问的核心交易类业务场景。

    • 分析型分布式数据库:通过横向扩展能力和并行计算能力,提升数据整体计算能力和吞吐量,支持海量数据的分析。主要应用于大规模结构化数据的统计分析、高性能交互式分析等场景,如数据仓库、数据集市等。

    • 交易分析混合型分布式数据库:通过资源隔离、分时和数据多副本等技术手段,基于不同的数据存储、访问性能和量等需求,使用不同的存储介质和分布式计算引擎,同时满足业务交易和分析需求。主要应用于数据规模大和访问并发量大,需要解决交易型数据同步到分析型数据库时成本高的问题,需要解决数据库入口统一的问题,需要支持高可用和高扩展性等数据处理业务场景。

    5. 数据处理组件

    为了提高应用性能和业务承载能力,降低微服务的耦合度,实现分布式架构下的分布式事务等要求,技术中台还有很多数据处理相关的基础技术组件

    如:分布式缓存、搜索引擎、数据复制、消息中间件和分布式事务等技术组件。

    • 分布式缓存是将高频热点数据集分布于多个内存集群节点,以复制、分发、分区和失效相结合的方式进行维护,解决高并发热点数据访问性能问题,降低后台数据库访问压力,提升系统吞吐能力。
      典型的开源分布式缓存技术组件有Redis。

    • 搜索引擎主要解决大数据量的快速搜索和分析等需求。

      将业务、日志类等不同类型的数据,加载到搜索引擎,提供可扩展和近实时的搜索能力。

    • 数据复制主要解决数据同步需求,实现同构、异构数据库间以及跨数据中心的数据复制,满足数据多级存储、交换和整合需求。

      主要应用于基于表或库的业务数据迁移、业务数据向数据仓库复制等数据迁移场景。

      数据复制技术组件大多采用数据库日志捕获和解析技术,在技术选型时需考虑数据复制技术组件与源端数据库的适配能力。

    • 消息中间件主要适用于数据最终一致性的业务场景,它采用异步化的设计,实现数据同步转异步操作,支持海量异步数据调用,并通过削峰填谷设计提高业务吞吐量和承载能力。

      它被广泛用于微服务之间的数据异步传输、大数据日志采集和流计算等场景。另外,在领域驱动设计的领域事件驱动模型中,消息中间件是实现领域事件数据最终一致性的非常关键的技术组件,可以实现微服务之间的解耦,满足“高内聚,松耦合”设计原则。典型的开源消息中间件有Kafka等。

    分布式事务主要是解决分布式架构下事务一致性的问题。单体应用被拆分成微服务后,原来单体应用大量的内部调用会变成跨微服务访问,业务调用链路中任意一个节点出现问题,都可能造成数据不一致。分布式事务是基于分布式事务模型,保证跨数据库或跨微服务调用场景下的数据一致性。

    分布式事务虽然可以实时保证数据的一致性,但过多的分布式事务设计会导致系统性能下降。

    因此微服务设计时应优先采用基于消息中间件的最终数据一致性机制,尽量避免使用分布式事务。

    技术中台是业务中台建设的关键技术基础。在中台建设过程中,可以根据业务需要不断更新和吸纳新的技术组件,也可以考虑将一些不具有明显业务含义的通用组件(如认证等),通过抽象和标准化设计后纳入技术中台统一管理。

    为了保证业务中台的高性能和稳定性,在技术组件选型时一定要记住:尽可能选用成熟的技术组件。

    展开全文
  • 技术中台的作用是什么? 技术前台 技术中台 在什么情况下,才有必要做技术中台? | 前提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懂个屁!我们都快被业务逼疯了,你们不就多费点人工吗?多加点班会死吗?总扯一些理念干嘛?对你没收益的事,你干嘛?”

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

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

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

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

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

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

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

    可悲,可叹。

    总结

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

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

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

    展开全文
  • 阿里巴巴中台战略最早从业务台和数据中台建设开始,采用了双中台的建设模式,到后来发展出了移动中台技术中台和研发中台等,这些中台的能力综合在一起就构成了阿里巴巴企业级数字化能力。传统企业在技术能力、...

    导读:2015年阿里巴巴提出“大中台,小前台”的中台战略,通过实施中台战略找到能够快速应对外界变化,整合阿里各种基础能力,高效支撑业务创新的机制。阿里巴巴中台战略最早从业务中台和数据中台建设开始,采用了双中台的建设模式,到后来发展出了移动中台、技术中台和研发中台等,这些中台的能力综合在一起就构成了阿里巴巴企业级数字化能力。传统企业在技术能力、组织架构和商业模式等方面与阿里巴巴存在非常大的差异,在实施中台战略时是否可以照搬阿里巴巴中台建设模式?传统企业中台数字化转型需要提升哪些方面的基本能力呢?下面我们一起来分析分析。

    作者:欧创新 邓頔

    来源:华章科技

    终于有人把业务中台、数据中台、技术中台都讲明白了

     

    00 中台能力总体框架

    中台建设过程从根本上讲是企业自身综合能力持续优化和提升的过程,最终目标是实现企业级业务能力复用和不同业务板块能力的联通和融合。

    企业级的综合能力,一般包含以下四种:业务能力、数据能力、技术能力和组织能力,如图2-1所示。

    终于有人把业务中台、数据中台、技术中台都讲明白了

    ▲图2-1 企业中台数字化转型基本能力框架

    • 业务能力主要体现为对中台领域模型的构建能力,对领域模型的持续演进能力,企业级业务能力的复用、融合和产品化运营能力,以及快速响应市场的商业模式创新能力。
    • 数据能力主要体现为企业级的数据融合能力、数据服务能力以及对商业模式创新和企业数字化运营的支撑能力。
    • 技术能力主要体现为对设备、网络等基础资源的自动化运维和管理能力,对微服务等分布式技术架构体系化的设计、开发和架构演进能力。
    • 组织能力主要体现为一体化的研发运营能力和敏捷的中台产品化运营能力,还体现为快速建设自适应的组织架构和中台建设方法体系等方面的能力。
    • 这些能力相辅相成,融合在一起为企业中台数字化转型发挥最大效能。接下来,我们一起来看看在不同的领域应该如何实现这些能力。

    01 业务中台

    企业所有能力建设都是服务于前台一线业务的。从这个角度来讲,所有中台应该都可以称为业务中台。但我们所说的业务中台一般是指支持企业线上核心业务的中台。

    业务中台承载了企业核心关键业务,是企业的核心业务能力,也是企业数字化转型的重点。业务中台的建设目标是:“将可复用的业务能力沉淀到业务中台,实现企业级业务能力复用和各业务板块之间的联通和协同,确保关键业务链路的稳定高效,提升业务创新效能。”

    业务中台的主要目标是实现企业级业务能力的复用,所以业务中台建设需优先解决业务能力重复建设和复用的问题。通过重构业务模型,将分散在不同渠道和业务场景(例如:互联网应用和传统核心应用)重复建设的业务能力,沉淀到企业级中台业务模型,面向企业所有业务场景和领域,实现能力复用和流程融合。

    图2-2是一个业务中台示例。在业务中台设计时,我们可以将用户管理、订单管理、商品管理和支付等这些通用的能力,通过业务领域边界划分和领域建模,沉淀到用户中心、订单中心、商品中心和支付中心等业务中台,然后基于分布式微服务技术体系完成微服务建设,形成企业级解决方案,面向前台应用提供可复用的业务能力。

    终于有人把业务中台、数据中台、技术中台都讲明白了

    ▲图2-2 业务中台示例

    在技术实现上,中台的系统落地可以采用微服务架构。微服务是目前公认的业务中台技术最佳实现,可以有效提升业务扩展能力,实现业务能力复用。

    在业务建模上,中台领域建模可以采用领域驱动设计(DDD)方法,通过划分业务限界上下文边界,构建中台领域模型,根据领域模型完成微服务拆分和设计。

    业务中台可以面向前台应用提供基于API接口级的业务服务能力,也可以将领域模型所在的微服务和微前端组合为业务单元,以组件的形式面向前台应用,提供基于微前端的页面级服务能力。

    业务中台建设完成后,前台应用就可以联通和组装各个不同中台业务板块,既提供企业级一体化业务能力支撑,又可以提供灵活的场景化销售能力支撑。

    02 数据中台

    数据中台与业务中台相辅相成,共同支持前台一线业务。数据中台除了拥有传统数据平台的统计分析和决策支持功能外,会更多聚焦于为前台一线交易类业务提供智能化的数据服务,支持企业流程智能化、运营智能化和商业模式创新,实现“业务数据化和数据业务化”。

    最近几年,数据应用领域出现了很多新的趋势。数据中台建设模式也随着这些趋势在发生变化,主要体现在以下几点。

    第一,数据应用技术发展迅猛。近几年涌现出了大量新的数据应用技术,如NoSQL、NewSQL和分布式数据库等,以及与数据采集、数据存储、数据建模和数据挖掘等大数据相关的技术。这些技术解决业务问题的能力越来越强,但同时也增加了技术实现的复杂度。

    第二,数据架构更加灵活。在从单体向微服务架构转型后,企业业务和数据形态也发生了很大的变化,数据架构已经从集中式架构向分布式架构转变。

    第三,数据来源更加多元化,数据格式更加多样化。随着车联网、物联网、LBS和社交媒体等数据的引入,数据来源已从单一的业务数据向复杂的多源数据转变,数据格式也已经从以结构化为主向结构化与非结构化多种模式混合的方向转变。

    第四,数据智能化应用将会越来越广泛。在数字新基建的大背景下,未来企业将汇集多种模式下的数据,借助深度学习和人工智能等智能技术,优化业务流程,实现业务流程的智能化,通过用户行为分析提升用户体验,实现精准营销、反欺诈和风险管控,实现数字化和智能化的产品运营以及AIOps等,提升企业数字智能化水平。

    面对复杂的数据领域,如何建设数据中台管理并利用好这些数据?

    这对企业来说是一个非常重要的课题。

    数据中台的大部分数据来源于业务中台,经过数据建模和数据分析等操作后,将加工后的数据,返回业务中台为前台应用提供数据服务,或直接以数据类应用的方式面向前台应用提供API数据服务。

    数据中台一般包括数据采集、数据集成、数据治理、数据应用和数据资产管理,另外还有诸如数据标准和指标建设,以及数据仓库或大数据等技术应用。图2-3是2017年阿里云栖大会上的一个数据中台示例。

    终于有人把业务中台、数据中台、技术中台都讲明白了

    ▲图2-3 数据中台示例(图参考:2017年阿里云栖大会)

    综上所述,数据中台建设需要做好以下三方面的工作。

    • 一是建立统一的企业级数据标准指标体系,解决数据来源多元化和标准不统一的问题。企业在统一的数据标准下,规范有序地完成数据采集、数据建模、数据分析、数据集成、数据应用和数据资产管理。
    • 二是建立与企业能力相适应的数据研发、分析、应用和资产管理技术体系。结合企业自身技术能力和数据应用场景,选择合适的技术体系构建数据中台。
    • 三是构建支持前台一线业务的数据中台。业务中台微服务化后,虽然提升了应用的高可用能力,但是随着数据和应用的拆分,会形成更多的数据孤岛,会增加应用和数据集成的难度。在业务中台建设的同时,需要同步启动数据中台建设,整合业务中台数据,消除不同业务板块核心业务链条之间的数据孤岛,对外提供统一的一致的数据服务。用“业务+数据”双中台模式,支持业务、数据和流程的融合。

    数据中台投入相对较大,收益周期较长,但会给企业带来巨大的潜在商业价值,也是企业未来数字化运营的重要基础。企业可以根据业务发展需求,制定好阶段性目标,分步骤、有计划地整合好现有数据平台,演进式推进数据中台建设。

    03 技术中台

    业务中台落地时需要有很多的技术组件支撑,这些不同技术领域的技术组件就组成了技术中台。业务中台大多采用微服务架构,以保障系统高可用性,有效应对高频海量业务访问场景,所以技术中台会有比较多的微服务相关的技术组件。

    一般来说,技术中台会有以下几类关键技术领域的组件,如API网关、前端开发框架、微服务开发框架、微服务治理组件、分布式数据库以及分布式架构下诸如复制、同步等数据处理相关的关键技术组件,如图2-4所示。

    1. API网关

    微服务架构一般采用前后端分离设计,前端页面逻辑和后端微服务业务逻辑独立开发、独立部署,通过网关实现前后端集成。

    前台应用接入中台微服务的技术组件一般是API网关。

    API网关主要包括:鉴权、降级限流、流量分析、负载均衡、服务路由和访问日志等功能。API网关可以帮助用户,方便地管理微服务API接口,实现安全的前后端分离,实现高效的系统集成和精细的服务监控。

    2. 开发框架

    开发框架主要包括前端开发框架和后端微服务开发框架。基于前、后端开发框架,分别完成前端页面逻辑和后端业务逻辑的开发。

    前端开发框架主要是面向PC端或者移动端应用,用于构建系统表示层,规范前后端交互,降低前端开发成本。

    终于有人把业务中台、数据中台、技术中台都讲明白了

    ▲图2-4 技术中台关键技术领域

    微服务开发框架用于构建企业级微服务应用。一般具备自动化配置、快速开发、方便调试及部署等特性,提供微服务注册、发现、通信、容错和监控等服务治理基础类库,帮助开发人员快速构建产品级的微服务应用。

    开发框架一般都支持代码自动生成、本地调试和依赖管理等功能。

    3. 微服务治理

    微服务治理是在微服务的运行过程中,针对微服务的运行状况采取的动态治理策略,如服务注册、发现、限流、熔断和降级等,以保障微服务能够持续稳定运行。

    微服务治理主要应用于微服务运行中的状态监控、微服务运行异常时的治理策略配置等场景,保障微服务在常见异常场景下的自恢复能力。

    微服务治理技术组件一般包括服务注册、服务发现、服务通信、配置中心、服务熔断、容错和微服务监控等组件。

    常见的微服务治理有Dubbo、Spring Cloud和Service Mesh等技术体系。

    4. 分布式数据库

    分布式数据库一般都具有较强的数据线性扩展能力,它们大多采用数据多副本机制实现数据库高可用,具有可扩展和低成本等技术优势。

    分布式数据库一般包括三类:交易型分布式数据库、分析型分布式数据库和交易分析混合型分布式数据库。

    • 交易型分布式数据库用于解决交易型业务的数据库计算能力,它支持数据分库、分片、数据多副本,具有高可用的特性,提供统一的运维界面,具备高性能的交易型业务数据处理能力。主要应用于具有跨区域部署和高可用需求,需支持高并发和高频访问的核心交易类业务场景。
    • 分析型分布式数据库通过横向扩展能力和并行计算能力,提升数据整体计算能力和吞吐量,支持海量数据的分析。主要应用于大规模结构化数据的统计分析、高性能交互式分析等场景,如数据仓库、数据集市等。
    • 交易分析混合型分布式数据库通过资源隔离、分时和数据多副本等技术手段,基于不同的数据存储、访问性能和容量等需求,使用不同的存储介质和分布式计算引擎,同时满足业务交易和分析需求。主要应用于数据规模大和访问并发量大,需要解决交易型数据同步到分析型数据库时成本高的问题,需要解决数据库入口统一的问题,需要支持高可用和高扩展性等数据处理业务场景。

    5. 数据处理组件

    为了提高应用性能和业务承载能力,降低微服务的耦合度,实现分布式架构下的分布式事务等要求,技术中台还有很多数据处理相关的基础技术组件。如:分布式缓存、搜索引擎、数据复制、消息中间件和分布式事务等技术组件。

    • 分布式缓存是将高频热点数据集分布于多个内存集群节点,以复制、分发、分区和失效相结合的方式进行维护,解决高并发热点数据访问性能问题,降低后台数据库访问压力,提升系统吞吐能力。典型的开源分布式缓存技术组件有Redis。
    • 搜索引擎主要解决大数据量的快速搜索和分析等需求。将业务、日志类等不同类型的数据,加载到搜索引擎,提供可扩展和近实时的搜索能力。
    • 数据复制主要解决数据同步需求,实现同构、异构数据库间以及跨数据中心的数据复制,满足数据多级存储、交换和整合需求。主要应用于基于表或库的业务数据迁移、业务数据向数据仓库复制等数据迁移场景。数据复制技术组件大多采用数据库日志捕获和解析技术,在技术选型时需考虑数据复制技术组件与源端数据库的适配能力。
    • 消息中间件主要适用于数据最终一致性的业务场景,它采用异步化的设计,实现数据同步转异步操作,支持海量异步数据调用,并通过削峰填谷设计提高业务吞吐量和承载能力。它被广泛用于微服务之间的数据异步传输、大数据日志采集和流计算等场景。另外,在领域驱动设计的领域事件驱动模型中,消息中间件是实现领域事件数据最终一致性的非常关键的技术组件,可以实现微服务之间的解耦,满足“高内聚,松耦合”设计原则。典型的开源消息中间件有Kafka等。

    分布式事务主要是解决分布式架构下事务一致性的问题。单体应用被拆分成微服务后,原来单体应用大量的内部调用会变成跨微服务访问,业务调用链路中任意一个节点出现问题,都可能造成数据不一致。分布式事务是基于分布式事务模型,保证跨数据库或跨微服务调用场景下的数据一致性。

    分布式事务虽然可以实时保证数据的一致性,但过多的分布式事务设计会导致系统性能下降。因此微服务设计时应优先采用基于消息中间件的最终数据一致性机制,尽量避免使用分布式事务。

    技术中台是业务中台建设的关键技术基础。在中台建设过程中,可以根据业务需要不断更新和吸纳新的技术组件,也可以考虑将一些不具有明显业务含义的通用组件(如认证等),通过抽象和标准化设计后纳入技术中台统一管理。为了保证业务中台的高性能和稳定性,在技术组件选型时一定要记住:尽可能选用成熟的技术组件。

    关于作者:欧创新,某大型保险公司架构师,拥有十多年的软件架构设计经验。热衷于DDD、中台和分布式微服务架构设计。在DDD、中台和分布式微服务架构设计方面有深厚的积累,擅长分布式微服务架构设计。邓頔,某大型保险公司高级工程师,全国青年岗位能手。致力于基于DDD的企业级中台微服务架构改造实践,精通前端开发相关技术栈,拥有丰富的企业级微前端实战经验。

    本文摘编自《中台架构与实现:基于DDD和微服务》,经出版方授权发布。

    终于有人把业务中台、数据中台、技术中台都讲明白了

    延伸阅读《中台架构与实现》

    推荐语:资深架构师撰写,系统阐述基于DDD的中台和微服务建设方法论,深刻揭示中台从领域建模到微服务落地完整过程。

    展开全文
  • 什么是技术中台

    千次阅读 2021-06-08 14:01:04
    导读:什么是技术中台技术中台说白了就是强调资源整合、能力沉淀的平台体系,当技术前台实现业务功能时,为他们提供底层的技术、数据等资源和能力的支持。 ▌技术中台赋能企业敏捷业务 主要是提高并发的需求。...
  • 互联网技术中台

    千次阅读 2019-09-09 22:06:54
    在有些人眼里:中台就是技术平台,像微服务开发框架、Devops平台、PaaS平台,容器云之类的,人们都叫它“技术中台”。 在有些人眼里:中台就是微服务业务平台,像最常见的什么用户中心,订单中心,各种微服务集散地...
  • 前台、中台与后台的概念 前台: 这里所说的“前台”和“前端”并不是一回事。所谓前台即包括各种和用户直接交互的界面,比如web页面,手机app;也包括服务端各种实时响应用户请求的业务逻辑,比如商品查询、订单系统...
  • 文/技术领导力社区编辑/Emma阿里中间件高级技术专家 钟华、高级技术专家 泠茗、中间件技术专家 玄难,在公开分享和访谈提到阿里技术中台建设实践,包括:技术中台、移动...
  • 前台、后台我知道,中台是什么呢? 今天一早起来,整个互联网圈都被腾讯的组织架构调整刷屏了,甚至有些人对腾讯新的6大事业群如数家珍,侃侃而谈,搞得比对自家公司的组织架构还清楚一样。 腾讯进行组织架构调整...
  • 中台架构实际由若干个层次组成,其中微服务技术中台是构建中台架构的重要组成部分。SpringCloud和Kubernetes,是目前互联网企业构建微服务技术中台所采用的主流技术栈,波波也会分析和比对这两个方案。Kubernetes...
  • 白话解读“中台技术

    千次阅读 2019-08-14 12:47:58
    什么是中台系统?它是如何诞生的?它长什么模样?我们为什么需要它?一串串的问题不禁浮现在我们的脑海,今天我们就带着这些问题,一起走进中台。什么是中台中台诞生任何一个软件系...
  • 中台建设方案

    千次阅读 2022-03-03 10:22:27
    企业中台建设参考
  • 导读:中台的存在价值是为它的客户服务,比如业务台和数据中台要快速响应前台应用的需求。 但如果中台同时服务于多个前台应用,在资源有限的情况下,必然涉及对来自不同应用的需求的优先级排序和取舍。如果前台...
  • DDD到底是什么概念,和微服务和中台之间又有什么样的联系,带你走进DDD!!
  • 中台技术简介

    千次阅读 2020-01-08 11:41:27
    中台技术全景 移动中台 业务中台 技术架构图 技术选型 ServiceMesh... 数据中台 技术中台技术组件的高可以部署及多租户问题的解决。 redis,mq,db...... 研发(效能)...
  • 大白话中台系统

    千次阅读 2019-11-11 10:44:47
    什么是中台系统?它是如何诞生的?它长什么模样?我们为什么需要它?一串串的问题不禁浮现在我们的脑海,今天我们就带着这些问题,一起走进中台。  1、中台诞生  任何一个软件系统都是通过帮助客户解决问题来...
  • 大数据中台

    千次阅读 多人点赞 2020-08-28 11:17:11
    数据中台的由来 数据中台最早是阿里提出的,但真正火起来是2018 年,我们能感受到行业文章谈论数据中台的越来越多。大量的互联网、非互联网公司都开始建设数据中台。为什么很多公司开始建设数据中台?尽管数据中台...
  • 一文读懂数据中台技术架构

    千次阅读 2020-11-02 22:11:52
    一文读懂数据中台技术架构 https://www.toutiao.com/i6836923386560512516/?tt_from=weixin&utm_campaign=client_share&wxshare_count=1&timestamp=1603853943&app=news_article&utm_source=...
  • 另一方面,云计算等技术的进步为SaaS发展提供了基础设施和底层技术。”十月底腾讯发布SaaS生态“千帆计划”,腾讯云副总裁答治茜如是说。 在此之际,腾讯也首次披露其在SaaS领域的打法,SaaS市场要迈向新高度,...
  • 小企业建立中台的条件

    千次阅读 2022-04-12 17:08:40
    2019年起不少小企业跟风建立了中台,然而到2021年末就很少呼声了,从招聘网站的岗位数量上也可观察出来。中台的撤销,很大程度源于财务部的核算:建中台后支出剧增。如果业务收入未能如期增长,那么中台肯定在降本...
  • 数据中台建设的价值架构 数据中台的终极使命是赋予数据资产价值变现的能力,无论是通过业务赋能的形式隐性变现,还是通过数据服务公开交易的直接变现。它们都需要一个很重要的基础条件“数据资产化”。 数据中台...
  • 1、解读中台 -- 什么是中台

    千次阅读 2019-10-06 18:57:15
    中台,通过对业务、数据和技术的抽象,对服务能力进行复用,构建了企业级的服务能力,消除了企业内部各业务部门、各分子公司间的壁垒,适应了企业,特别是大型企业集团业务多元化的发展战略。基于中台,可快速构建面向最终...
  • 数据中台技术的利与弊

    千次阅读 2019-10-08 17:56:46
    伴随信息时代的发展,新技术、新框架、新语言层出不穷,解决问题的技术视角其实从来没有改变。...实际上数据中台技术主要面临的挑战主要也是计算服务和各种数据存储如何便捷的统一起来,并通过服务化 API...
  • 点击“技术领导力”关注∆每天早上8:30推送作者| Mr.K 编辑| Emma来源|引力山丘小米中台建设实践01小米的三大中建设:业务+数据+技术业务中台-...
  • 数据中台四大核心体系

    千次阅读 2022-03-15 14:33:36
    数据中台核心体系建设
  • 中台的理解分析与建设

    千次阅读 2020-11-18 18:17:15
    业务中台、数据中台、业务中台
  • 数据台和业务中台的区别

    千次阅读 2020-11-16 09:24:02
    业务中台让前台开发更敏捷,为什么业务中台起的作用是把多个交易权,比如用户查用户创建订单的API,你的生成库存入库单的这种API全部把它合并成一个,然后让前台去调用,它是为了让前台开发更敏捷,速度更快,而且更...
  • 数据中台总体技术架构

    千次阅读 2020-04-20 22:53:28
    数据中台技术架构说明通用数据中台技术架构基于阿里云组件的技术架构 说明 中台的概念热了将近两年,有人认为中台是趋势,有人认为中台是炒作。 笔者(个人微信号:comjavaba)认为中台的本质是能力共享,就像任何...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 1,341,566
精华内容 536,626
关键字:

技术中台

友情链接: scaling.rar