转载本文需注明出处：微信公众号EAWorld，违者必究。
做为企业数字化中台建设支撑的技术中台，其前台是企业应用，后台是企业基础设施（网络、存储、计算等资源），可为企业数字化中台建设提供标准化、端到端、柔性（可变化）的软件生产能力，从而提高企业IT系统建设的效率与可用性。本文节选《金融企业数字化中台》部份内容，重点介绍如何建设技术中台。
前端
技术中台建设的范畴数据库
汽车制造的全生命周期对应到软件系统：小程序
-
部件包括几种类型：业务组件、集成组件、技术组件和基础设施组件，这些是软件系统运行的基本部分，其中业务组件主要由业务中台、数据中台提供，基础设施一旦肯定变化不大，属于技术中台的后台，技术中台主要关注集成组件、技术组件。
-
汽车的结构对应到软件系统就是软件的技术架构，即软件系统经过何种方式将部件组合起来运行，相同的部件能够经过不一样方式的组合，产生不一样的运行方式，技术架构能够分为企业集成架构和应用技术架构两种类型，前者是企业中各应用间互联互通的模式，后者是各独立应用的运行模式，不一样业务特征的应用能够有不一样的运行模式；
-
流程对应软件的全生命周期过程，一样能够分为产品设计、软件开发、软件维护几个阶段，造成几个软件工程的“流水线”；
-
最后，软件生产也须要不少工具，例如开发工具、监控工具、需求工具等等。
所谓集成就是要作整合，从业务使用视角和实施运维的视角看，相关集成组件通常有页面集成、流程集成、服务集成、数据集成和一些其余公共的集成所需组件，例如统一身份认证、统一应用门户框架、统一任务中心、统一组织机构用户、统一流程集成、服务集成、批量文件传输、做业调度等等。
身份认证或身份验证（Authentication）就是对应用程序的“访问者”身份进行验证识别。访问者分两类，一类是须要“用户”登陆的客户端；另一类是“API客户端”，即设备或者应用程序。
认证过程当中，最多见的身份标识就是帐号和密码。实际状况中不一样渠道的用户登陆方式不一样，须要支持各类不一样帐号登陆。企业内部系统常以员工帐号、密码登陆为主，比较统一；而对客类业务帐号类型就五花八门了，如：客户帐号、手机号、邮箱、身份证号、银行卡号、法人机构号等等。所以对于不一样登陆方式的支持，用户与帐号的关系应为1:N，即从概念模型上支持一个用户从不一样渠道使用不一样的帐号登陆。
组织机构用户数据是企业运营的基础数据，IT系统中的业务运行离不开组织机构数据。金融企业的IT建设规模大，动辄数以百计的业务系统，若是组织机构数据听任由业务系统各自管理维护，会形成数据标准不统一，系统集成统计等工做没法进行，大量数据的映射转换工做将让人望而却步，长此以往就出现了一个个孤岛应用。
对于组织数据标准化，首先须要定义组织机构、岗位、角色、用户等组织机构实体的惟一编码和名称，编码格式要有章可循，并制定好编码规范和管理规则，进而能够精确到数据库字段的名称、类型和长度一致，实现数据标准统一。
有了标准化的组织机构数据，并不意味着一成不变。随着企业发展壮大、业务运营的变化，组织机构也会进行调整以适应新的企业运营模式。结合大型金融企业的一些特色，组织机构数据要具有柔性（可变性）的特色。常见的组织机构的柔性以下：
-
兼容组织机构数据的多样性，如：支持“多法人”模式。
-
在主体框架范围内，支持不一样业务维度下组织数据的可变性，如：“多维度”模式。
-
组织机构数据集成方式的多样性，如：支持远程接口调用、数据同步共享等集成方式。
企业门户是企业现有应用与新应用的集成节点，使用户可以与人员、内容、应用和流程进行个性化的、安全的、单点式的互动交流。它也是一个集成的、可配置的、个性化定制的工做环境，能够随时随地提供给员工、客户和合做伙伴使用，是企业实现高效管理的重要工具和手段。
不管是对客或是对内或是面向不一样终端技术类型的门户，一般都具有以下特色：
（1）建设内容管理服务，支撑企业信息、知识的通用管理发布
（2）“内容管理系统”与“业务应用系统”的链接与集成
任务中心简单来说就是整个企业业务人员的待办任务数据池。任务中心能够接收来自流程平台或其余应用系统推送过来的任务、通知、流程等任务数据。业务人员访问业务门户的任务中心应用后，对本身当前的任务能够一目了然，这样既避免了业务人员处理不一样业务的时候在不一样的业务系统之间的菜单切换，也方便了业务人员对不一样业务系统数据之间的比对和分析，使得业务人员将更多的精力专一于业务，进而提高工做效率，节约业务成本。
建设统一的集中式任务中心，须要从任务数据的生命周期角度全面考虑，即：任务收集、任务查询、任务结束等几个阶段对任务数据和状态的管理，同时还须要对于任务中心的集中管理、权限进行考量：
创建标准化数据模型，集成企业任务数据，被动接收外部收集的数据（推荐）。安全
对于流程、任务、通知数据的管理，都应该根据其生命周期进行合理的规划。服务器
在已有业务系统之间打通服务还是ESB的核心任务。面对新一代数字化转型中的业务的需求，须要可以围绕一个简单、灵活的标准协议对全部新应用进行链接，相对而言Web Service协议略显沉重，ESB因为其集中式枢纽的地位，快速响应变动对于它来讲也不是很合适。
在数字化转型时代，在金融企业中 ESB 与API Gateway是共存的，都是IT系统之间的服务集成平台。ESB做为系统之间的服务集成的枢纽，网关则在微服务架构体系的业务领域内部进行系统之间集成通讯。不管是ESB仍是网关，做为服务集成平台的建设来讲，重点应该关注的内容包含：身份验证、权限管控、服务路由能力加强等方面。复杂的服务组装、数据、协议转换工做一般须要编码开发，灵活度低，容易产生故障，不建议在服务集成平台中实施，这类工做建议交给负责交易流应用实施的平台负责。
统一的文件传输解决方案具备集中管理、自动化、实时触发、无人值守等特性，更适合金融企业的实际需求，能够助力企业下降成本，加速业务流转效率。文件传输平台定位为能够面向分布式应用的文件传输平台，应该具有良好的可扩展性、处理性能，且易于管理和维护。要可以抽象各类传输场景和模式，提供多样化的策略配置手段，以达成实现不一样节点间的文件可靠、安全、高效传输的目标。
做为企业级的统一文件传输平台，须要支持多种传输的场景，在高效性、高可靠性、安全性、可管控性、平台自身运维能力等方面着重考虑：
-
-
-
-
集中式的全面的做业运行情况分析、预警和系统状态监控。
技术中台设计原则中提到了精益运营理论TOC，落地以DevOps为核心的数字化的软件生产线时也是利用TOC方法论来审视软件生产的全流程，查找其中的瓶颈、制约因素和浪费，而后考虑和践行解决方式，经过度量来考察成果。先来看一下广泛存在的浪费现象。
大中型项目全生命周期建设和投产流程，一般用于大型项目群的管理过程，以及新增系统的建设管理过程。
小型项目全生命周期建设和投产流程，一般用于已有系统的优化、依据业务或技术迭代进行变动管理的过程。
紧急上线流程，一般用于基于SLA保障的紧急处置过程管理。
基于DevOps的数字化要与软件生产线全流程相融合，不仅是须要软件生产的全流程第一级的流程环节，还须要第二级，甚至第三级的子流程（或流程活动环节）。
-
每一个流程活动对应的输入，明确其必选项和可选项，明确其必选项的检查标准（是否可将其结构化，是否可经过程序自动检查其完成程度）。
-
每一个流程活动对应的输出，明确其必选项和可选项，明确其必选项的检查标准（是否可将其结构化，是否可经过程序自动检查其完成程度）。
-
每一个流程活动对应的角色，经过RACI（R：流程由谁发起，A：由谁负责审批，C：若有问题咨询谁，I：流程完成后通知谁）的模型进行表述，从而明确此流程活动的分工操做界面。
-
要完成此活动须要使用的工具，而且结合其输入、输出，可否将其加工生产的过程自动化。
咱们在分析完每一个2、三级子流程（活动）以后，可明确各串联流程活动之间的交付物（此输出为彼输入），以及交付物的质量标准（必选项是哪些，必选项要完成到什么程度才能流入到下一流程活动环节），每一个活动的分工梳理清晰以后，才能打通各活动对应的工具造成自动化的工具链，使工件自动化流转。
经过以上的讲述，但愿你们可以理解，软件生产过程当中的精益运营没有那么的“阳春白雪”，更多作的是“下里巴人”的事情。在工业生产中，精益改进体如今流水线工人是经过按钮、仍是经过扫描枪、或是经过拉绳通知下游工序环节。若是用了按钮，按钮是放在流水线上（会不会引发误操做），仍是放在旁边的柱子上（要不要工人起身）。在软件生产中，其实也是同样的道理，开发人员的代码是每日提交仍是单个功能开发完后提交，后续触发的代码评审是天天都审核代码，仍是按功能点审核。以上种种都是要在实践中摸索和实践才能找到最适合的点，而且每一个组织又由于自身的状况，解决方式又不尽相同。
基于金融行业的特色，提供一些度量视图的建议，从而使咱们经过度量，在了解如何建设数字化的软件生产线基础上，可以持续优化咱们的生产线。
-
项目群视角：
项目群是金融科技管理过程当中一个很具特点的项目协同管理方式。在金融企业中，一般单一业务需求或合并后的业务需求会触发多个系统的配合改造来知足，这就出现了一个主项目、多个配合项目协同开发、协同投产的状况。
-
部门视角：
部门视角则是由科技管理团队/部门划分来决定，并为部门管理来提供决策支撑。在金融企业中，一般按核心类、渠道类、管理类、信贷类进行部门团队的划分。建议将一些引领性指标引入到部门管理之中，并按日/周提供报表、排名、风险等，帮助部门管理者提供决策依据。
-
单一系统视角：
对于单一系统，依据系统的重要程度和团队大小的差别，开发模式一般分为多月度版本（多特性）并行（如：核心和信贷等系统）和单月度版本串行的模式，也可能根据建设周期的不一样在二者之间进行切换。
打造敏捷转型的五横四纵体系，支撑最大化的业务产出和软件价值的快速交付：
-
横向端到端的工具链打通、五大环境标准化与资源流转、数字化软件生产线与科技管理各级流程融合、产物及质量门禁标准造成、引领指标造成及精益持续改进，部门间的组织融合
-
纵向需求、开发、测试、运营的敏捷化转型，规则、标准、规范的设定，系统间复杂集成架构的构建与支撑
DevOps的本质，是在软件生产过程当中是落实精益运营思想，杜绝浪费，创建数字化生产线。
金融行业在引入DevOps以前，须要先考虑如下五点建议：
-
-
-
-
-
2）
基于开源的技术众多，选型复杂、困难，而且随着开源版本的升级，企业自行维护存在困难。
3）
系统复杂度大幅度提升，由于微服务将系统内的复杂度转移为系统间的复杂度了。
须要咱们掌握分布与聚合的原则，将面向的问题域分门别类创建起来，为各类技术实现找到明确的定位。分布与聚合这个矛盾的对立统一，咱们但愿达到：
-
服务分布、流程统一，即服务是分布式部署的，可是在业务逻辑上可以统一块儿来；
-
数据是分布，可是对外呈现的信息是聚合的，事务是完整的；
-
各分布式模块的感受（末梢神经）是分布的，但系统的知觉（大脑）是统一的
服务调用分为“服务提供者”和“服务消费者”两个角色，“服务提供者”将本身的服务地址等信息登记到“服务注册中心”中，调用者（“服务消费者”）从“服务注册中心”查询到提供者的信息，根据这些信息调用服务。
-
在客户端模式下，“服务消费者”在向“服务注册中心”查询到本身须要调用的“服务提供者”地址以后，“服务消费者”就会本身根据地址去直接访问微服务，此时须要客户端本身实现负载均衡逻辑。
-
在代理模式下，“服务消费者”经过 API Gateway 组件与微服务、“服务注册中心”链接。“服务消费者”只管去找 API Gateway 访问便可。至于去注册中心查询服务地址，以及访问服务地址的动做都由 API Gateway 代劳了，最后 API Gateway 在把结果返回给“服务消费者”便可。
服务运行一般要设定一些参数，这些参数以往以配置文件的形式存在。此外，咱们在进行业务开发的时候，通常会有多个环境，例如开发环境、测试环境、生产环境，这是传统的配置文件没法解决的。
集中式的服务配置管理，让咱们告别投产或运维手工修改配置的方式，统一管理全部微服务节点的配置，提高运维的效率。
配置文件主要有运行前的静态配置和运行期的动态配置两种。静态配置一般是在编译部署包以前设置好。动态配置则是系统运行过程当中须要调整系统变量或者业务参数。要想作到集中的配置管理，须要注意如下几点：
1）
配置与介质分离，这个就须要经过制定规范的方式来控制。千万别把配置放在Jar包里。
2）
配置的方式要统一，格式、读写方式、变动热更新的模式尽可能统一，要采用统一的配置框。
3）
运行时须要有个配置中心来统一管理业务系统中的配置信息，这个就须要平台来提供配置中心服务和配置管理门户。
数据是企业应用的核心，企业应用也是围绕着数据展开，当系统数据愈来愈庞大的时候，咱们就须要考虑将数据拆分，分而治之。表面上使用微服务架构后，必然出现数据的分布，实际上正是因为数据须要分布，才产生了微服务架构。一方面，随着目前移动互联网、物联网的发展致使数据量愈来愈大，另外一方面“下主机”“自主可控”等架构要求致使单机处理能力有所下降，所以须要进行数据分布。
根据 CAP 原理，一致性、可用性、分区容忍性三者没法同时知足，咱们不奢望找到全能的方案，但能够应该根据不一样场景归集到几种模式，制定相应的处理策略。
（三）TCC模式（Try-Confirm-Cancel）
1）
都要求服务提供者在正常的交易以外，提供额外的功能，貌似带来了代码的复杂度，加大了工做量。实际上都是业务需求中必备的，例如：TCC 模式在交易系统中都有预扣款这样的接口，并不会增长实现的工做量。而对于服务的调用者来讲，相关服务的调用由微服务框架实现，例如自动的事件投放、自动补偿调用、TCC中 CC 服务的调用，也不须要额外的工做量；
2）
如何从当前上下文向补偿接口、confirm接口、cancel 接口传递参数？实际上只要将正向交易的数据传递过去便可，不须要额外的数据；
3）
若是补偿仍是失败，该怎么办？仍是须要对帐的。
1）
心跳监测：提供模拟交易，由系统主动提供运行状态信息。
2）
日志记录：系统将运行状况记录下来，用于感受后端服务的运行状况。
3）
字节码注入：注入到服务端代码中，用于感受后端服务的运行状况。
4）
客户端埋点：注入到客户端代码中，用于感受前端的运行状况。
“感受”探查到的信息汇总造成完整的“知觉”，例如：
1）健康检查：知晓微服务健康状态，了解服务的可用性，避免调用到失效服务上。
2）性能分析：知晓微服务运行的性能，了解整个系统的瓶颈，在实时分析的基础上进行预警，在问题萌芽的阶段发觉并告警，下降问题影响的范围和时间。
3）业务监控：知晓业务交易状况，监测业务访问量、慢交易数量、业务时延及发生错误的次数等各项业务指标。
4）故障定位：知晓微服务的拓扑结构、调用关系和调用顺序，实时搜集信息并进行聚合分析，了解系统和应用中发生的事件，尽可能避免故障，而且在发生故障后快速定位故障，减小处理时间。
创建微服务架构下系统的知觉能力，须要多个层面配合完成，是一个系统性的工程，而不是孤立的考虑。咱们把系统的“知觉”能力纵向分为四个层次，客户端（Web、H五、APP、小程序等）、服务端（微服务进程）、技术组件（虚机、容器、中间件、数据库等）、基础设施（网络、服务器、存储等）。“知觉”体现的最终行动，分为链路拓扑、监控、预警、故障定位、趋势分析等几个主题；配置中心（CMDB）实现全部涉及到的应用软件、系统软件、服务器和网络设备的配置管理、监控参数设置、业务规则配置，监控中心负责监控展现与告警；分析中心根据“感受”采集的数据进行深度挖掘，积累知识。
关于做者：黄荣，数字化金融研究院研究员，擅长系统分析和架构设计、金融三级密钥安全体系及信息安全保障、虚拟化和云计算技术、JavaEE技术；参与研发的神州商桥电子商务平台得到“全国电子商务示范单位”称号；带领团队研发的国电通云终端系统在国网多个省公司推广应用。架构
关于EAWorld：微服务，DevOps，数据治理，移动架构原创技术分享。长按二维码关注！负载均衡