技术中台建设的范畴
汽车制造的全生命周期对应到软件系统：
- 部件包括几种类型：业务组件、集成组件、技术组件和基础设施组件，这些是软件系统运行的基本部分，其中业务组件主要由业务中台、数据中台提供，基础设施一旦确定变化不大，属于技术中台的后台，技术中台主要关注集成组件、技术组件。
- 汽车的结构对应到软件系统就是软件的技术架构，即软件系统通过何种方式将部件组合起来运行，相同的部件可以通过不同方式的组合，产生不同的运行方式，技术架构可以分为企业集成架构和应用技术架构两种类型，前者是企业中各应用间互联互通的模式，后者是各独立应用的运行模式，不同业务特征的应用可以有不同的运行模式；
- 流程对应软件的全生命周期过程，同样可以分为产品设计、软件开发、软件维护几个阶段，形成几个软件工程的“流水线”；
- 最后，软件生产也需要很多工具，例如开发工具、监控工具、需求工具等等。
01 应用集成架构：整合企业应用能力
应用集成架构：整合企业应用能力
所谓集成就是要做整合，从业务使用视角和实施运维的视角看，相关集成组件一般有页面集成、流程集成、服务集成、数据集成和一些其他公共的集成所需组件，例如统一身份认证、统一应用门户框架、统一任务中心、统一组织机构用户、统一流程集成、服务集成、批量文件传输、作业调度等等。
统一身份认证
身份认证或身份验证（Authentication）就是对应用程序的“访问者”身份进行验证识别。访问者分两类，一类是需要“用户”登录的客户端；另外一类是“API客户端”，即设备或者应用程序。
认证过程中，最常见的身份标识就是账号和密码。实际情况中不同渠道的用户登录方式不同，需要支持各种不同账号登录。企业内部系统常以员工账号、密码登录为主，比较统一；而对客类业务账号类型就五花八门了，如：客户账号、手机号、邮箱、身份证号、银行卡号、法人机构号等等。因此对于不同登录方式的支持，用户与账号的关系应为1:N，即从概念模型上支持一个用户从不同渠道使用不同的账号登录。
统一组织机构
组织机构用户数据是企业运营的基础数据，IT系统中的业务运行离不开组织机构数据。金融企业的IT建设规模大，动辄数以百计的业务系统，如果组织机构数据放任由业务系统各自管理维护，会造成数据标准不统一，系统集成统计等工作无法进行，大量数据的映射转换工作将让人望而却步，久而久之就出现了一个个孤岛应用。
对于组织数据标准化，首先需要定义组织机构、岗位、角色、用户等组织机构实体的唯一编码和名称，编码格式要有章可循，并制定好编码规范和管理规则，进而可以精确到数据库字段的名称、类型和长度一致，实现数据标准统一。
有了标准化的组织机构数据，并不意味着一成不变。随着企业发展壮大、业务运营的变化，组织机构也会进行调整以适应新的企业运营模式。结合大型金融企业的一些特点，组织机构数据要具备柔性（可变性）的特点。常见的组织机构的柔性如下：
- 兼容组织机构数据的多样性，如：支持“多法人”模式。
- 在主体框架范围内，支持不同业务维度下组织数据的可变性，如：“多维度”模式。
- 组织机构数据集成方式的多样性，如：支持远程接口调用、数据同步共享等集成方式。
统一应用门户
企业门户是企业现有应用与新应用的集成节点，使用户能够与人员、内容、应用和流程进行个性化的、安全的、单点式的互动交流。它也是一个集成的、可配置的、个性化定制的工作环境，可以随时随地提供给员工、客户和合作伙伴使用，是企业实现高效管理的重要工具和手段。
不论是对客或是对内或是面向不同终端技术类型的门户，通常都具备如下特点：
- 统一应用入口：
（1）与授权服务器集成，支持SSO单点登录
（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：流程完成后通知谁）的模型进行表述，从而明确此流程活动的分工操作界面。
- 要完成此活动需要使用的工具，并且结合其输入、输出，能否将其加工生产的过程自动化。
我们在分析完每个二、三级子流程（活动）之后，可明确各串联流程活动之间的交付物（此输出为彼输入），以及交付物的质量标准（必选项是哪些，必选项要完成到什么程度才能流入到下一流程活动环节），每个活动的分工梳理清晰之后，才能打通各活动对应的工具形成自动化的工具链，使工件自动化流转。
打造数字生产线需要做到的五个统一
通过以上的讲述，希望大家能够理解，软件生产过程中的精益运营没有那么的“阳春白雪”，更多做的是“下里巴人”的事情。在工业生产中，精益改进体现在流水线工人是通过按钮、还是通过扫描枪、或是通过拉绳通知下游工序环节。如果用了按钮，按钮是放在流水线上（会不会引起误操作），还是放在旁边的柱子上（要不要工人起身）。在软件生产中，其实也是一样的道理，开发人员的代码是每日提交还是单个功能开发完后提交，后续触发的代码评审是每天都审核代码，还是按功能点审核。以上种种都是要在实践中摸索和实践才能找到最适合的点，并且每个组织又因为自身的情况，解决方式又不尽相同。
度量与引领性指标必不可少
基于金融行业的特点，提供一些度量视图的建议，从而使我们通过度量，在了解如何建设数字化的软件生产线基础上，能够持续优化我们的生产线。
- 项目群视角：项目群是金融科技管理过程中一个很具特色的项目协同管理方式。在金融企业中，通常单一业务需求或合并后的业务需求会触发多个系统的配合改造来满足，这就出现了一个主项目、多个配合项目协同开发、协同投产的情况。
- 部门视角：部门视角则是由科技管理团队/部门划分来决定，并为部门管理来提供决策支撑。在金融企业中，通常按核心类、渠道类、管理类、信贷类进行部门团队的划分。建议将一些引领性指标引入到部门管理之中，并按日/周提供报表、排名、风险等，帮助部门管理者提供决策依据。
- 单一系统视角：对于单一系统，依据系统的重要程度和团队大小的差异，开发模式通常分为多月度版本（多特性）并行（如：核心和信贷等系统）和单月度版本串行的模式，也可能根据建设周期的不同在两者之间进行切换。
以DevOps为基础的数字化生产线
打造敏捷转型的五横四纵体系，支撑最大化的业务产出和软件价值的快速交付：
- 横向端到端的工具链打通、五大环境标准化与资源流转、数字化软件生产线与科技管理各级流程融合、产物及质量门禁标准形成、引领指标形成及精益持续改进，部门间的组织融合
- 纵向需求、开发、测试、运营的敏捷化转型，规则、标准、规范的设定，系统间复杂集成架构的构建与支撑
DevOps的本质，是在软件生产过程中是落实精益运营思想，杜绝浪费，建立数字化生产线。
金融行业在引入DevOps之前，需要先考虑以下五点建议：
- 小步快跑好过一蹴而就
- 没有“银弹”
- 数字化生产线的建设不能只依赖于工具层面
- 精益运营思想
- 逐步形成精细化管理
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）实现所有涉及到的应用软件、系统软件、服务器和网络设备的配置管理、监控参数设置、业务规则配置，监控中心负责监控展示与告警；分析中心根据“感觉”采集的数据进行深度挖掘，积累知识。
推荐阅读
数据中台建设从数据中台的认知开始
业务中台建设从结构化需求开始
数字化中台建设的过程与方法
