技术中台落地实战

　　本篇带领大家来看一看在技术层面要如何实现这些中台设计方案。
　　本章不会涉及过多的技术术语，尽量保证我们非技术专业出身的同学也能看懂本章的设计实 现理念。1.1 技术中台体系架构
　　大家应该也能猜到技术中台作为中台的底层，其核心使命就是为各条业务线提供真正的代码 实现，从而支撑各部门达成业务目标。
　　而在上层的数据中台与业务中台里我们已经提出了复用与模块组合的新型设计架构，那么公 司的实现底层也必须改变传统的实现模式去支持这种业务需求，正因如此，我们就演化出了所谓 的技术中台。具体在企业的软件体系中，技术中台的层级如图12- 1所示。
　　图12-1 技术中台的层级
　　前面我们已经以产品经理的视角将公司的研发人员分为了前台业务研发人员、 中台研发人 员、后台研发人员 3类。而如果再站在公司的技术实现层面，也就是以技术人的视角来看整个研 发团队，可以发现公司的技术团队可以重新拆分为技术前台、技术中台与技术后台3个部分。
　　技术前台是为前台业务部门进行需求开发的团队，如卖家平台业务线中的开发团队。技术前 台的研发人员的核心价值体现在对业务逻辑的理解与实现上，他们响应业务方的具体需求，如系 统主题色、业务流程等功能。
　　技术中台类似一个承上启下的中间层，对下封装复杂的实现逻辑，对上提供统一化的工具。 例如，如果一家公司有多个数据库，我们在开发时每次对数据库的操作都要编写多个面向不同数 据库的代码，而技术中台就将此封装起来，在前台业务中只用写业务逻辑，由技术中台来翻译成 实际存储数据的数据库与数据库操作语言。
　　此外也将整个公司的技术能力与业务能力分离开来，让负责业务逻辑的这群人专心去完成业 务实现，将性能与调优等这些内容交由中台完成，从而大大降低前台技术开发的能力标准，实现 了＂火力交替布置＂的效果，大大节省了企业的人力资源成本。
　　此时技术中台就像是一个大型的工具箱，里面放满了各式各样被打磨得相当锋利的技术工
　　具，任一前台人员在开发中拿起来使用即可。大家平时听到的一些＂高大上＂的技术名词，如分布式 文件存储、分布式数据库、分布式缓存等这些中间件就是由技术中台所提供的。
　　技术后台在本质上负责我们与物理世界沟通的中间环节，通过封装底层的物理机器操作而向 技术中台提供对应服务，他们负责让冷冰冰的机器运作起来去描绘五彩缤纷的互联网世界。
　　还是以前面电商案例来看，如果结合案例中得到的业务中台，我们可以得到公司内技术团队 的体系架构，如图12-2所示。
　　图12-2 电商技术团队的体系架构
　　在任何项目的初期，系统中绝大多数功能都是非常简单的，往往在技术实现上只需要利用数 据库的原子操作CRUD[1] 就能满足绝大多数需求，因此整个系统的架构也是非常清晰的。但随着系 统迭代与业务的不断演化，整个系统中的业务逻辑变得越来越复杂，代码实现也变得越来越冗 杂，此时系统内模块彼此关联，数据交互频繁。
　　例如，笔者之前见过在一个项目中查询会员的邀请人与自己的邀请信息居然要查询将近数十 张表。这样的复杂实现就导致项目成员没有一个人能说清楚所有模块的具体功能意图，造成在修 改一个功能时往往光回溯该功能最初的设计就需要很长时间，更不用说修改带来的不可预知的影 响。
　　再看一个典型的反面案例，假设我们现在要实现一个电商中的订单模块，在该模块中我们要 实现订单信息查询、订单修改、订单支付、订单评价4个功能。
　　而很多时候研发同学在编写实现代码时会为了省事就直接编写统一的订单服务去解决上面的 所有功能，在该服务中我们提供了订单查询接口、订单修改接口、订单支付接口、订单评价接 口，该服务实现示意图如图12-3所示。
　　图12-3 订单服务实现示意图
　　而这些接口同时访问我们整个服务统一对应的订单表，该表涵盖所有功能所需的字段：
　　订单基本信息：订单的编号、订单产生时间、购买人、店铺名称、商品名称、商品数 量、商品规格等。
　　订单状态信息：订单进行状态、支付状态、货物出库状态等。
　　相关功能信息：订单评价信息、物流配送信息等。
　　这样的实现方式在初次建设时看似比较简单，整个实现工作量也不是很大。但是当我们为下 一个功能去开发代码时就会发现非常大的问题，很可能我们有时候只想修改订单创建功能，结果 因为没有考虑到关联字段的错误而影响到了订单评价等功能，此时的结果就是我们在每次修改完 订单相关功能的时候，都需要对整个订单服务进行全链路的功能测试，而随着订单这个模块的功 能越来越庞大，我们的测试与维护时间会呈几何式增长。
　　而这个问题的症结就是我们在创建服务时，该功能模块的整体架构不是很清晰，并没有将一 个服务对象拆分成多个边界清晰的模块，让一个独立单元只完成一件事情。
　　＂一件事由一个单元独立完成＂的思想，其实就对应上了在前面中台规划设计中的能力，也是 能快速完成新项目研发的核心，各大业务线将自己的业务切割成若干的事件，在实现时直接调用 技术中台中早已封装好的服务单元即可。而随着技术中台的不断拓展，涵盖的能力越多，前台业
　　务线能调用的服务越多，需要自主研发的地方就越少。
　　而这一切就是技术中台要帮助我们最终实现的，通过若干个＂魔法＂帮我们实现这些中台的终极 目标＂通用性＂与＂复用性＂ 。接下来我们就来看看究竟要如何施展这些＂魔法＂。1.3 如何搭建技术中台
　　1.3.1 SOA
　　在一般公司内部，技术中台的核心由标准的SOA[2] 搭建。而SOA直译过来是＂面向服务的架 构＂。
　　让我们来看一个SOA的标准定义。ThoughtWorks 公司的技术专家、 内部系统架构师Sam Newman在《微服务设计》一书中是这样定义的：＂SOA是一种设计方法，其中包含多个服务，而 服务之间通过配合最终会提供一系列功能。一个服务通常以独立的形式存在于操作系统进程中。 服务之间通过网络调用，而非采用进程内调用的方式进行通信。＂SOA组成关键模块如图12-4所 示。
　　图12-4 S OA组成关键模块
　　这一番话对于我们这些不搞技术的人来说确实是蛮难理解的。不过看完这段话之后，我们至 少对SOA有了这样的一个理解：SOA好像是将应用程序拆分为一个个的组件来实现的。那么这种架 构到底是怎么帮助我们将中台架构落实的呢？
　　举一个大家在日常生活中应该都见到过的例子来理解一下。在前两年一些电商网站在类似＂双 11＂活动中都会出现一个很经典的现象，就是在刚到0点那一瞬间，由于我们都在那个点提交订单， 此时订单页面会显示＂服务器异常，订单无法提交＂ ，这很显然是因为同时并发请求订单提交的人数 太多了。
　　但是奇怪的是，这个时候如果我们去使用其他模块，如查看收藏夹、浏览商品，这些模块都 是正常的，这就意味着在整个电商系统中只有订单模块暂时无法使用。那么这种现象的背后其实 就是SOA在发挥作用，再说明白点就是部分模块的故障不会导致整个系统的崩溃，也就是说我 们不会因为无法提交订单而无法使用整个电商系统。
　　所以通过这个案例，我们就明白了 SOA实际上就是将各个模块划分为独立单元去独立运
　　行，从而保证整个系统的安全 。看到这里大家肯定会产生疑惑，既然我们可以像正常写一个应 用一样去写应用中的一个个模块，再把它们独立发布到服务器上去实现这个架构中所谓的模块化 独立运行，那么这样的架构又是如何使松散的各个模块之间建立关系呢？
　　让我们再深入一点看看这种模块独立运行架构的实现方式，还是举一个通俗化案例来说明。
　　我们以一个公司为例，在公司创立的时候，所有的人都听老板的指挥；老板叫你做什么，你 就去做什么。随着企业的发展，人数不断增多，业务不断膨胀。那么这个时候事情也越来越多 了。如果所有的事情都让老板一个人去指挥，那么效率会变得非常低下。这个时候企业要做的最 重要的事情就是成立部门，于是乎公司内一下冒出了测试部、研发部、运营部等部门，我们开始 让每个部门只做本部门职能内的事。
　　但是部门制无法避免的一个现象就是需要跨部门的协作，但是作为某一个部门内的人员，你 要怎么知道找什么部门去完成什么事呢？此时我们就需要依赖一个行政部门去进行统一协调，每 一个新成立的部门都在行政部那里进行备案，如做什么事情的是哪些人员，然后公布出来让所有 的部门都知道，这个时候大家就可以在公共的地方查到对应的信息了。
　　在这个案例中，我们能看到如下几个阶段。
　　第一阶段： 在公司刚成立时老板统一指挥所有员工，实际上映射的就是我们在项目刚刚启动 的时候将所有的功能都写到一个服务中去，此时一旦任何一个功能出现了问题，整个系统都无法 正常运行。
　　第二阶段： 随着业务的复杂化，演化出的各个部门实际上就类似于我们在架构中将一个个功 能独立打包成应用并独立上线，此时就能保证不会出现由于订单模块无法访问导致其他模块不能 正常使用的情况。
　　第三阶段： 部门的增多让每个部门内的人很难去了解到整个公司的全貌，这里其实就像在一 个应用中随着功能的增多，当我们需要调用其他模块的服务时，例如在购物车模块调用登录验证 服务以判断用户是否处于登录状态，我们需要统一的注册中心告诉我们请求的地址与请求的参数 是什么，从而让我们完成应用内的通信。而每当有新服务变更线上地址，注册中心则统一通知所 有的接口，这就是服务发布。
　　所以我们就能理解，SOA可以将分散在企业各个组的资源与代码进行统一整合与管理，并在组 内的各个模块发生变化时，使用专门的注册中心进行服务调度与通知。也正是服务调度的方式使 得原有各个系统以及新构建的系统有机结合成为一个整体。
　　在前文中，我们也提到了业务中台，实际上业务中台就是将一个个的模块进行复用。那么从 技术实现来看：中台实际就是将每一个复用的模块作为一个独立的应用进行开发与上线，再 通过服务调度来实现复用。1.3.2 核心：微服务
　　对微服务最简单的理解就是把系统按照不同的业务对象，根据提供的服务拆分成一个个大小 合适并且可以独立部署的模块，每个模块相互独立但又可以任意组合从而形成可复用的架构。
　　比如，现在一个电商网站按照微服务的定义将会变为如下形式：
　　如果我只想要随便看看，会用到商品服务、广告服务、搜索服务等。
　　如果我想看我以前的订单，会用到登录服务、商品服务、订单服务。
　　如果我想买东西，从登录这个网站到搜索挑选商品再到成功下单，调用了登录服务、 搜索服务、商品服务、购物车服务、订单服务、支付服务。
　　模块已经被我们拆分清楚了，那么刚在定义里提到的模块可复用究竟是什么呢？
　　再举个案例来看，比如现在我们要做一个多终端的员工管理系统，此时整个系统包含PC端、 安卓客户端、iOS客户端3部分。
　　假设现在我要编写一个员工通讯录功能，这个功能需要从数据库中读取注册员工的相关信 息。如果我们不使用微服务去拆分，系统的实现模式是先在PC端中写一个查询方法，再从数据库 中查询员工信息，然后在网页上展示。而安卓客户端与iOS客户端也是一样的，需要分别写一个查
　　询方法，去数据库中查询注册员工的数据，然后在App上显示。
　　此时我们可以一眼看出来，这里有3个查询方法是高度相似的。这样的坏处就很明显了：3个 终端都有相似的业务代码，一旦我们的底层出现了变动，例如我们更换了数据库中的字段或者数 据库表名，此时这3处的业务代码都需要进行修改。
　　所以这个时候我们就需要通过微服务的思想，将注册员工信息管理整体包装成一个独立的服 务。我们可以单独创建一个项目，将这个服务部署到一台独立的服务器上，这个服务自身通过一 个方法去统一访问数据库中的员工信息，此时再为这个服务编写可以提供返回数据的方法，只要 有其他服务去请求这个方法接口，就会返回通用数据类型 (json 、xml等) 的数据给它。
　　也就是说，我们可以把该事件的所有操作封装到一套代码中，然后让有该事件需要的终端直 接访问这套代码，这套代码也就形成＂服务＂ 。这样我们就完成了注册用户服务的开发。关于注册用 户的所有相关增、删、改、查的操作，这个服务都会提供具体的操作。
　　这样一来，无论是PC端还是手机端都可以直接通过这个服务获得最新的员工数据，各条业务 线不需要再关心底层的变化。而当业务发展而需要对注册员工的信息进行维度升级时，只需要单 独修改这一服务。这里也就将原来客户端开发人员既要开发通讯录显示界面又要开发数据库操作 的这种杂糅式研发，成功地变为两组人员独立维护自己范围内的代码片段，用研发同学的专业术 语来说这就叫作＂解耦＂。
　　同理，我们刚才在上面提到了电商中的其他模块，我们可以将其单独开发成服务并部署在单 独的服务器上。
　　这里的案例都是在告诉我们要将系统进行不断的拆分，从而实现复杂问题单一化处理。那么 仅仅实现了微服务还不能称之为SOA，因为它缺少了服务治理环节。也就是说，当我们这样的微型 服务越来越多的时候，我们要想实现高效的各个服务之间的调用，就要依靠我们SOA中另一个重要 的部分——我们的注册中心去进行服务治理。
　　什么是服务治理？当服务越来越多而调用方也越来越多的时候，这两者关系就会变得非常混
　　乱，而且由于每个服务都是由一个独立的团队去进行维护迭代的，那么我们没有办法去实时搞清 楚所有的服务信息变化，因此我们需要统一的对这些关系进行管理的工具。
　　再举一个例子来解释。比如我们有一个用户管理服务，一开始只有自营电商中心与卖家中心 在使用。而随着公司业务线的拓展，我们增加了供应商中心、审计中心等，它们都需要调用用户 管理服务。这个时候作为用户管理的提供方，我们只知道为多个模块提供了服务，却不知道具体 为谁提供了服务。
　　这种单向联系的模式也就带来了一个隐患，当它自身发生变化的时候，如针对业务扩展后的 需求而增加了一个接口以提供将企业内部人员与企业外部人员进行区分管理的功能，此时我们就 无法很方便地通知到这些调用方。
　　同时由于这些业务需求方只通过接口调用了用户管理服务，作为服务的提供方，我们也无法 对不同的调用方进行管理。最常见的问题：在我们的计算资源有限的情况下，要优先为哪一个需 求方提供用户管理服务呢？
　　因此我们需要一个类似于注册中心的结构，在这里由调用方主动上报调用的申请人与相关信
　　息，再由服务方主动上报变更信息。通过此＂服务中介＂ ，我们能自动化管理企业内部资源，实现资 源协调。
　　再举个极端的例子，如果我们不使用SOA的方式进行实现，当我们后台所发布的服务有一天因 为服务器出现了故障而必须更换服务器和域名时，由于我们各个服务器的域名都是直接在App代码
　　中＂写死＂的，我们要进行替换就需要把每一个终端代码打开去挨个进行服务器地址替换。
　　而替换完毕之后，我们还需要重新将App端的应用进行打包发布，再提交应用商店审核，以让 用户去更新，这中间平白增加了非常多的流程和环节。如果任何一个环节出了问题，如应用商店 审核时间长、用户更新失败等，而由于之前的服务已经访问不到了，这时候用户面对的就只能是 一个存在故障的应用。在这一段完全不可控的空窗期内，整个业务无疑蒙受巨大的损失。所以我 们不难看到，SOA为我们的整个系统服务带来的帮助是巨大的。
　　可以说技术中台在整个企业的软件系统中是一个举足轻重的环节，承载着整个中台的思想的 落地与实现，而能将这一切＂魔法＂变为现实的核心就是我们的SOA。1.3.3 技术中台的并入
　　现在我们就可以将技术中台引入并同步更新整个公司的技术架构了，新的技术架构总体上分 为5个部分，即展现层、接口层、服务层、数据运营和外挂系统，如图12-5所示。
　　我来总结下这个新的系统架构：
　　最上层是展现层，这里是我们的各条前台业务线，主要为移动端和PC端，由接口层直 接访问技术中台。
　　中间层是接口层，负责提供统一的接口体系以完成展现层与服务层间的数据交互。
　　下层是服务层，包含3个部分，技术前台是对业务中台的技术实现，技术中台提供底层 服务，技术后台提供直接访问底层硬件相关管理。
　　左侧是外挂系统，负责提供不同场景的系统与我们的系统的数据对接服务。
　　右侧是数据运营，负责提供数据分析服务，也就是我们的数据中台的技术实现。
　　图12-5 中台加入后的IT系统架构
　　至此我们已经成功地将技术中台嵌入原来公司的系统群了，伴随着技术中台的篇章结束，至 此我们整个中台方案就已经全部介绍完毕了。总结
　　知识点1：搭建技术中台
　　搭建技术中台在本质上就是引入SOA来重塑公司的技术体系。
　　SOA=微服务+注册中心
　　知识点2：微服务
　　微服务将业务拆分成独立的模块，让每个模块可以独立上线运行。
　　知识点3：注册中心
　　微服务统一管理微服务的模块，向各条业务线实时提供微服务模块的运行信息与地址，以便 其他业务方可以动态获知服务的更新。