技术架构基础组件简介

背景

传统企业大多采用集中式架构，技术体系相对落后，可扩展能力不强。集中式架构过于依赖设备资源，基于稳定或性能考虑，大多运行在大型机或小型机上。同时，传统企业多采用“两地三中心”的容灾模式高可用能力不强，难以实现多中心多活，也容易带来资源浪费的问题。
在运维能力上，过于依赖人工，难以实现自动化运维，面对突发高频访问的业务场景不能实现自动弹性伸缩。当业务量到达一定规模后，集中式数据库的容量利性能问题也容易成为业务发展的瓶颈。
总而言之，传统的集中式架构技术体系已经难以适应新形式下的业务发展要求。基于微服务架构来构建企业级应用已成为业界趋势。微服务架构很好地实现了应用解耦，可以更好地实现应用上云。解决单体应用扩展和弹性伸缩能力不足的问题。
技术中台就是将使用云或其他基础设施的能力各种技术中间件的能力进行整合和包装。过滤掉技术细节，提供简单一致，易于使用的应用技术基础设施的能力接口，助力前台和业务中台数据中台的快速建设。

理清技术中台各个关键组件

业务中台落地时需要有很多的技术组件支撑，这些不同技术领域的技术组件就组成了技术中台。业务中台大多采用微服务架构，以保障系统高可用性。有效应对高频海量业务访问场景，所以技术中台会有比较多的微服务相关的技术组件—般来说，技术中台会有以下几类关键技术领域的组件。如API网关、前端开发框架、微服务开发框架、微服务治理组件、分布式数据库以及分布式架构下诸如复制、同步等数据处理相关的关键技术组件。

1. API网关

微服务架构—般采用前后端分离设计，前端页面逻辑利后端微服务业务逻辑独立开发独立部署，通过网关实现前后端集成。前台应用接人中台微服务的技术组件—般是API网关。API网关主要包含鉴权、降级限流、流量分析、负载均衡、服务路由和访问日志等功能。API网关可以帮助用户，方便地管理微服务API接口，实现安全的前后端分离,实现高效的系统集成和精细的服务监控。

2. 开发框架

开发框架主要包括前端开发框架和后端微服务开发框架。基于前、后端开发框架。分别完成前端页面逻辑和后端业务逻辑的开发。前端开发框架主要是面向PC端或者移动端应用，用于构建系统表示层,规范前后端交互，降低前端开发成本。微服务开发框架用于构建企业级微服务应用。—般具备自动化配置、快速开发、方便调试及部署等特性,提供微服务注册、发现、通信、容错和监控等服务治理基础类库,帮助开发人员快速构建产品级的微服务应用。开发框架—般都支持代码自动生成、本地调试和依赖管理等功能。

3. 微服务治理

微服务治理是在微服务的运行过程中,针对微服务的运行状况采取的动态治理策略,如服务注册、发现、限流、熔断和降级等，以保障微服务能够持续稳定运行。微服务治理主要应用于微服务运行中的状态监控、微服务运行异常时的治理策略配置等场景，保障微服务在常见异常场景下的自恢复能力。微服务治理技术组件一般包括服务注册、服务发现、服务通信、配置中心、服务熔断、容错和微服务监控等组件。常见的微服务治理有Dubbo、SpringCloud和ServiccMesh等技术体系。

4. 分布式数据库

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

5. 数据处理组件

为了提高应用性能和业务承载能力，降低微服务的藕合度,实现分布式架构下的分布式事务等要求，技术中台还有很多数据处理相关的基础技术组件。如:分布式缓存、搜索引擎、数据复制、消息中间件利分布式事务等技术组件。分布式缓存是将高频热点数据集分布于多个内存集群节点,以复制、分发、分区和失效相结合的方式进行维护,解决高并发热点数据访问性能问题降低后台数据库访问压力,提升系统吞吐能力。典型的开源分布式缓存技术组件有Redis搜索引擎主要解决大数据量的快速搜索和分析等需求。将业务、日志类等不同类型的数据，加载到搜索引擎，提供可扩展和近实时的搜索能力。数据复制主要解决数据同步需求，实现同构、异构数据库间以及跨数据中心的数据复制,满足数据多级存储、交换和整合需求。主要应用于基于表或库的业务数据迁移、业务数据向数据仓库复制等数据迁移场景。数据复制技术组件大多采用数据库日志捕获和解析技术，在技术选型时需考虑数据复制技术组件与源端数据库的适配能力。消息中间件主要适用于数据最终-致性的业务场景，它采用异步化的设计，实现数据同步转异步操作，支持海量异步数据调用，并通过削峰填谷设计提高业务吞吐量和承载能力。它被广泛用于微服务之间的数据异步传输、大数据日志采集和流汁算等场景。另外，在领域驱动设计的领域事件驱动模型中,消息中间件是实现领域事件数据最终—致性的非常关键的技术组件,可以实现微服务之间的解藕，满足“高内聚,低耦合”的设计原则。典型的开源消息中间件有Kafka等。分布式事务主要是解决分布式架构下事务—致性的问题。单体应用被拆分成微服务后，原来单体应用大量的内部调用会变成跨微服务访问，业务调用链路中任意一个节点出现问题,都可能造成数据不一致。
分布式事务是基于分布式事务模型，保证跨数据库或跨微服务调用场景下的数据—致性。分布式事务虽然可以实时保证数据的—致性,但过多的分布式事务设计会导致系统性能下降。因此微服务设计时应优先采用基干消息中间件的最终数据一致性机制,尽量避免使用分布式事务。

结论

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