前言

航司PSS、E-Commerce、Customer Service等三大层级应用及系统群，在互联网+的冲击下，及日新月异的个性化旅客诉求的推动下，必须进行服务化及更开放的能力暴露，以期敏捷化的、模块化的去适应新业务，单一个性需求等等场景。

那从行业领域的Open API，到NDC，再联想到技术领域Web Service，SOA，Microservices等都是将传统应用和系统，尤其是集群型的Block状的业务能力打散为更有活力且可复用的服务模块，同时增强服务治理的能力，将服务变为产品和能力，及新业务的基础。

两点注解：

a) 打散 - 打散不代表重建，更不代表对于厚重的Block状的系统的彻底改造、模块化、或革新升级，而是梳理其业务、数据、上下文场景下的逻辑打散，让任何人都明白这些Block状的系统能干什么、哪些场景需要它们、在哪些环节出现他们。即“功能的黄页”，“功能的API手册”。

b) 治理 - 如何将已经实物化的服务接口应用变为可发现、可跟踪、可授权的真正“服务API的黄页”。

误解 - “全部抛弃后重建”

航司电商进行微服务架构或服务架构体系转型的时候，一定不是把原来遗留IT系统全部抛弃后而全部基于微服务架构重新构建新的业务系统，因此转型过程中更加需要考虑遗留架构下中台如何演进，或者说航司在基础的PSS等核心业务系统都存在的情况下，中台如何演进。

核心 - SOA

借用Baidu百科的介绍：SOA是一个组件模型，它将应用程序的不同功能单元（称为服务）通过这些服务之间定义良好的接口和契约联系起来。接口是采用中立的方式进行定义的，它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种各样的系统中的服务可以以一种统一和通用的方式进行交互。 不同种类的操作系统，应用软件，系统软件和应用基础结构（application infrastructure）相互交织，这便是IT企业的现状。一些现存的应用程序被用来处理当前的业务流程（business processes），因此从头建立一个新的基础环境是不可能的。企业应该能对业务的变化做出快速的反应，利用对现有的应用程序和应用基础结构（application infrastructure）的投资来解决新的业务需求，为客户，商业伙伴以及供应商提供新的互动渠道，并呈现一个可以支持有机业务（organic business）的构架。SOA凭借其松耦合的特性，使得企业可以按照模块化的方式来添加新服务或更新现有服务，以解决新的业务需要，提供选择从而可以通过不同的渠道提供服务，并可以把企业现有的或已有的应用作为服务， 从而保护了现有的IT基础建设投资。

（Leo：所以不管是微服务，还是行业的Open API，乃至NDC，都是想对于即有的能力进行暴露，通过快捷便利的IT手段，以期通过复用得到更大的价值。）

思路

a) 以服务组件和服务能力开放思路来构建中台

如果原来的业务系统已经存在同时又不希望对已有的系统进行大的改造和变更，那么在这种情况下中台构建的一个思路就是构建一个服务平台，或者我们常说的OpenAPI能力开放平台。这个平台的重点是服务组件，而不是业务组件，服务组件本身并不太承载业务规则和逻辑的实现。

也就是说把服务组件的实现，API接口服务的开发和暴露从原有的业务系统中单独拿出来进行构建，这里的服务组件既可以是数据服务组件，也可以是业务服务组件，同时还可以在中台进行服务的组合，形成组合服务组件，然后再有服务组件暴露API接口开放出去。

如果业务服务组件那么可以路由回已有的业务系统，如果是数据服务组件则可以直接访问业务系统的后台数据库来进行数据服务能力的实现。在服务组件层，仍然可以按照业务域，或者按照数据分类对服务组件进行划分，比如订单中心，库存中心，供应商中心，产品中心等，但是这些服务组件本身没有业务规则的实现，更多仅仅是服务能力的暴露。

也就是说对传统的业务系统进行横切，在数据库或逻辑层上增加了一个服务层，这个服务层是所有业务系统共同的业务服务能力层，提供和暴露服务能力。这种服务能力的暴露可以用来构建新的业务系统需要。而对于传统已有的业务系统本身可以不做任何改动。这样至少可以保证新业务系统的构建灵活和解耦。

（Leo：核心就是SOA：Common Service、Biz Service、Data Service等。原有系统不变，在其上将系统和应用的能力进行梳理后，单独在Expose出来的Web Service。且多半后续会设计ESB或BPM，进行业务流程重组和编排。）

b) 基础共性数据能力下沉思路来构建中台

简单来说就是将基础主数据能力，大范围共享数据从原有的业务系统中剥离出来，将这些剥离的内容单独构建为一个个独立的微服务模块。这些微服务模块的重点是提供和暴露各类共享数据服务能力。比如可以将供应商管理内容从采购系统中剥离出来，单独建设一个供应商中心，然后将供应商的查询，变更等能力暴露出去，单独供其它业务系统使用。

由于这种思路更多的都是基础和共性数据能力的下沉和剥离，类似传统IT架构中MDM主数据平台的建设，因此相对来说对业务系统的影响较小，也容易进行剥离和单点构建。同时这类微服务模块本身没有太复杂的业务规则和逻辑需要实现，相对来说更加容易实施和集成。

(Leo：其实就是ODS的一个关键部分。通过Metadata和Master Data标准化数据，然后聚合到一个centralized的运营层次的数据存储，然后expose给外部消费的Data Service集合。)

在a)和b)两种方式进行中台构建的时候，API服务的暴露最好都是以查询服务能力为主，这样可以最小化的对原有的业务系统和数据库逻辑造成影响。简单来说，如果一个遗留业务系统后续更多的是提供查询能力给其它业务系统使用，那么ESB集成商在了解数据库结构后，也完全有能力来构建完成的中台服务层。在前面我有一篇文章专门讲到过，ESB集成商本身两个发展方向，一个是产品化的纯技术平台，一个是能够提供标准化和模块化服务资产的厚服务平台。

c) 遗留业务系统进行前后端分离和组件拆分改造

相对前两个来说，这个思路是工作量和改造难度都最大的一个思路。比如原来的一个电商B2C系统，需要全面进行微服务架构改造，由原来的单体应用改造为基础数据、Shopping、Booking、Ticketing、Payment、Order等等微服务模块。

那么这种改造就相对困难，首先就是原有的业务系统要进行完成的垂直拆分，即单体应用从数据库到逻辑层再到前端展现都需要纵向独立的拆分松耦合的微服务模块。其次是单个微服务模块本身也希望将前端和后端之间进行分离，中间插入一个关键的服务层解耦。

在这种改造模式下，各个微服务模块需要涉及到和外部其它业务系统相互协同的就可以独立构建为独立的各个中心。这些中心就会纳入到中台进行统一管理和能力开放。即各个纳入到中台的中心既满足了业务本身的业务流程和业务需求，同时又能够发布为API接口服务，供外网的其它业务系统访问和调用。

（Leo：这也许就是很多人头脑里的DDD和Microservices的实现。然而事实并不是这样，而且也没有任何人有这样的魄力，尤其是航司这种企业级且牵扯GDS和TTL的业务系统平台。）

服务中台

来源

多大半来自于阿里。因为其发展近乎20年，大量可复用重用的资源，且有公共服务部门运营，所以这些Common的东西就需要得到良好的治理变为可再生的资源。

阿里提出的"轻前台，重中台"，就是入口服务尽量简洁，中台服务做大的适配，这样新的项目可以重用中台服务而不用重新写一套代码。用户点击支付，请求会走到支付的入口服务去，这个入口服务可以被称作前台。前台需要获取一些数据，比如用户信息，订单信息等，就需要访问用户中心和订单中心，这两个被称之为中台；而具体的后台是指前台和中台需要调用到的一些基础服务，而db、缓存、log、消息队列等则被称之为中间件。

另：其可以理解为是互联网架构的一个新概念，可以理解为介于前台和后台之间的链接系统，因为互联网架构中会依赖很多第三方服务和接口，后台通常只做自己的核心业务，那么和第三方对接的服务就放在了某一个平台中具体实现，逐渐就有了「中台」的概念。

优势

a) 服务重用：真正体现SOA理念的核心价值，松耦合的服务带来业务的复用。

b) 服务进化：随着新业务的不断接入，共享服务也需从仅提供单薄业务功能，不断的自我进化成更健壮更强大的服务，不断适应各种业务线，真正成为企业宝贵的IT资产。

c) 数据累积：各个业务的数据都沉淀在同一套中台服务，可以不断累积数据，最终发挥大数据威力。

d) 快速响应：更快的通过共享服务的组合响应新业务。

e) 降低成本：对于新业务，无需再投入新的重复的开发力量，减少人员成本。

f) 效能提升：开发人员更专注某一领域，开发更快，更易维护。

挑战

对于服务端开发人员来说，更具有挑战性。各业务流量汇聚中台服务，服务是否能扛得住大流量、高并发、高可用；以及为适应不同业务线，中台服务的抽象设计能力也是很大的挑战。

BaaS(Back-end as a Service)

简而言之将IaaS及PaaS与NFR相融合而提供的服务模式。让应用和系统开发者更能够关注于业务实现。

但是其不是直接能够被服务中台，尤其是航司的服务中台直接使用的底层服务或后台服务。

（Leo：此处暂不特别介绍）

航司电商服务中台

a) 不是Open API的概念和实现载体。

b) 只对内Internal使用，例如诸多大型航司自己的b2c平台中的服务群组。

c) 可以作为NDC的下层实现，但是NDC最好的下层是航司电商的微服务群组。

d) 颗粒度相对较难把握，但是按照Shopping、Booking、Payment、Ticketing、Order、Customer.....等分割比较合理。

e) 不包含任何NFR的或者Common/Utilization的服务。

f) 不会涉及ESB的使用或对接。

g) 不涉及基础后台的服务化。例如不能简单的将航信的IBE接口封装后expose出去。

h) 不涉及数据的服务化，即无Data Service。

（Leo：但是个人认为，一个航司要将积累的数年的成果转变为一个服务中台的形式，其实很艰辛。就拿支付来说，如果只是一个外部算好帐，支付只完成支付的提交、连结网关、记录交易等等。还相对简单，但是往往对于一些支付时的计算或规则，如果梳理不好，或对于未来变化无法预估，会让支付包含一定的外部业务逻辑。）

待续......