数字化企业的API架构治理 – ThoughtWorks洞见

在前文中我们说到，传统企业在逐步建设自己的数字平台过程中，需要抓住交付基础设施、API和架构治理、数据自服务、创新实验基础设施和监控体系、用户触点技术这五个支柱。今天我们就来谈一谈API、架构治理这些听起来非常技术性的概念与企业的数字化战略之间有何关系。

企业资源服务化

从1990年代起，企业资源计划（ERP）一直是企业信息化的核心议题。植根于供应链管理，ERP通过对企业内部财务会计、制造、进销存等信息流的整合，提升企业的计划能力与控制能力。然而近年来，在互联网的冲击下，传统企业开始面临全新的挑战。尤其是在互联网的去中介化效应影响下，原本在供应链上下游各安其位的企业突然间都被压缩到了“生产-流通-消费”这个极度精简的价值链中。药品购销两票制就是这个极简价值模型的直观呈现。在这个模型中，掌握技术优势和消费者入口的互联网企业有可能形成一家独大的超级垄断，挤死传统的流通企业，把生产企业变成自己的OEM厂商，这是传统企业对来自互联网的竞争者恐惧的根源。

为了对抗互联网企业的竞争，传统企业最好的办法不是硬拼互联网上的技术和流量，而是在自己擅长的领域开战：把自己多年积累的线下资源变成线上服务，构建起本行业的线上生态系统，不仅支撑本企业的线上经营，而且为上下游周边企业提供线上经营的平台，从而把线下优势转化为线上优势，以资源优势对抗技术优势。

为了支撑企业资源的服务化，在设计在线服务的API和架构时需要考虑以下问题：

• 平台架构和API的设计应该注重开发者体验。
• 在API的背后，应该从业务功能的角度出发划分合理的限界上下文和服务边界，对外提供高内聚低耦合的服务。
• 在服务边界之间，应该考虑使用异步的事件机制实现服务之间的通信，来解耦领域模型，客观地描述运行时间比较长、甚至本质上不可能立即完成的操作。
• 为了方便使用，应该提供API网关作为所有服务使用者的单一入口，在API网关背后去处理众多内部IT系统的复杂性。
• 整个API架构应该以微服务的风格呈现，避免典型SOA架构中普遍存在的过于复杂的ESB编排逻辑。

ERP之后是什么？

进入2010年代以来，“后ERP时代”这个说法不断被提出。在谈到ERP的发展方向时，通常都会涉及业务与技术两个角度。例如一种观点认为，ERP需要从以流程为中心转变为以客户为中心，并且需要用好云计算、社交网络、大数据和移动化等新技术。

ThoughtWorks认为，ERP在互联网时代的发展方向将是企业资源服务化（Enterprise Resource Servicification，ERS），通过数字平台的技术能力，把一家企业的资源融入一个行业的互联网生态，为企业铺下明确的数字化道路。

API和架构治理解读

下面我们来近距离看看，在“API和架构治理”这顶帽子下面，有哪些具体的问题需要被考虑到。

开发者体验

当企业资源以服务的形式对外提供，也就意味着不可能——像传统的IT系统建设那样——强迫别人使用这些服务。尤其是要把这些服务提供给第三方开发者、希望他们开发出形形色色的应用程序，那么服务的API是否易用就会很大程度上影响它能吸引到多少第三方开发者。ThoughtWorks第16期技术雷达还专门把开发者体验作为一个重要的技术主题。

在讨论开发者体验时，可以从开发工具和开发环境的安装、配置、管理、使用、维护等角度来考量。具体而言，开发环境和测试环境是否能弹性地随需获得，开发/测试基础设施和持续交付流水线是否以源代码的形式提供并完全自动化，是否提供对主流开源软件的支持，是否提供可编程的、命令行友好的（而不仅仅是图形化的）工具界面，安全、数据访问权限等企业规章是否严重影响开发者的效率和感受，这些都是影响开发者体验的要素。

和所有的面向对象设计一样，服务的设计应该是高内聚低耦合的：与一个业务相关的修改只在一个服务内部进行，并且一个服务的修改/部署不需要影响其他服务。和一个代码库内部的对象设计不同，每个服务通常有专属的代码库，并且由专人负责维护（而不是所有人拥有所有代码），因此服务边界的改变会带来更大的变更成本。所以，服务边界的划分需要投入精力认真对待。

从设计原则上来说，服务的边界应该体现业务的边界，而不是单纯从技术角度出发划分服务边界。从业务功能的角度出发划分合理的限界上下文，以领域模型和领域事件的聚合为出发点来划分服务，更可能得出与业务边界一致的服务边界。随后再以业务目标驱动建设全功能一体化团队，就能做到业务、技术、团队三者对齐（康威定律再次起作用）。四色建模、事件风暴等方法都能有效地实现领域驱动设计，从而建立起良好的领域模型及服务边界。

事件驱动架构

使用异步的事件机制实现服务之间的通信。对于运行时间比较长、甚至本质上不可能立即完成的操作（例如涉及人工操作），使用异步通信是合理的选择。即便不考虑响应的实时性，事件驱动的架构还表达了领域模型之间的松散耦合关系：跨领域的协作以事件而非方法调用的形式来表达，系统追求最终一致性而非强一致性。这一结构准确地映射了真实世界中多支相关但独立的团队之间的协作关系，避免了过度依赖其他服务的响应速度或可靠性等服务质量指标，使服务真正具有技术上的独立性。

在设计系统时，借助事件风暴方法，可以通过领域事件识别出聚合根，进而划分微服务的限界上下文。当出现跨多个聚合根的事件时，可以很自然地将其实现为异步的领域事件，从而获得与领域设计高度吻合的实现。关于如何设计和实现领域事件，可以参阅ThoughtWorks咨询师滕云的文章：《在微服务中使用领域事件》。

在实现事件驱动的架构时，当然可以沿用传统的SOA架构中的消息中间件。但由于微服务架构中，业务逻辑都存在于各个服务内部，没有庞大臃肿的ESB（稍后我们还会详谈这个问题），因此消息机制也不需要强大的服务编排（orchestration）能力。RabbitMQ这样标准的消息代理当然很好，也有很多系统（例如Bahmni）采用更简单的做法：领域事件发生时，以ATOM格式发布；关心特定领域事件的其他领域模型则订阅特定的ATOM feed主题。这种基于HTTP的事件传播方式最大的好处就是简单，几乎不需要增加新的软件就可以实现。不过这个方案在处理低延迟的场景时表现不佳。

微服务提供的API粒度与客户端的需求不同，所以客户端一个请求经常需要多个服务；服务端和客户端之间可能需要通信协议转换；不同的客户端对数据的需求不同，例如浏览器客户端需要的信息可能多于移动客户端；服务的终端信息（主机+端口）可能变化；不同数据片可能由不同的服务终端来提供——以上这些因素都指出：有必要对服务做一层门面封装，提供API网关作为所有服务使用者的单一入口点。

API网关处理请求的方式有两种：一种是直接代理/路由给合适的服务；另一种是由一个请求扇出/分发给多个服务。API网关可能针对不同客户端提供不同的API，可能包含针对客户端的适配代码。横切需求（例如安全）也可能在API网关实现。

当服务数量变多、API网关变大以后，维护一个通用的API网关会增加API网关层的复杂度，导致一个独立的“API团队”出现，协调和沟通的工作量加大。这时可以考虑引入公共网关的一个变体：为特定前端设计的后端（Backend For Frontend，BFF），即为每个前端应用提供一个单独的API网关，使对齐业务的一体化团队能够拉通前后端开发、而不必等待“API团队”完成他们的backlog。

API网关可以实现为一个独立的服务端应用，其代价则是增加一层复杂度（和出错的可能性）。为了降低这一代价，可以考虑用Zuul等工具来实现API网关。

微服务SOA拓扑

与传统的SOA架构相比，所谓“微服务”最大的特点可能就在于没有一个重量级的ESB。重量级的ESB有其历史原因。在2000年代业界刚开始采用SOA时，很多企业尽管把业务系统包装成了web服务，但IT团队的组织结构并没有发生改变，仍然是由一组人集中式地掌管整个业务流程——只不过系统集成的方式不再是直接的方法调用，而是服务编排（orchestration）。原本存在于集成代码中的复杂逻辑，现在被转移到了ESB中。而这个“ESB团队”成了IT交付的瓶颈：不论发布事件的服务还是消费事件的服务、或是编排逻辑本身的改变，与事件相关的变更都需要通过ESB团队。这个团队的backlog堆积起来，使得每个服务、每个应用都无法提供快速响应。

微服务架构更重视服务与业务的对齐。贝索斯所说的“两个pizza的团队”不仅负责一个IT系统的交付，而且要负责用这个IT系统来支撑一个业务的成功。为了做到单个服务能够独立开发、独立部署、独立运行，这支团队应该能够在很大程度上掌控自己的进度，而不依赖于一个集中式技术团队的进度。因此微服务应该通过服务注册与发现机制获得自己需要的依赖服务、自己判断是否要直接调用或订阅依赖服务的事件，每个服务包含与其业务对应的复杂度，而不是把整个系统的复杂度集中在ESB和编排逻辑上。整个系统的架构（以及团队的架构）应该呈现为若干个端到端拉通的、与业务对齐的纵切服务，而不是一个横切的大块（ESB）覆盖所有业务。

为了激活企业线下资源、打造行业线上生态，IT需要一套有效的服务API和架构治理方法。首先从领域驱动设计入手，划分出合理的限界上下文和服务边界，然后用异步消息机制来描述领域事件。设计好的服务通过API网关或BFF暴露给前端应用，把依赖关系和集成逻辑约束在与业务对齐的一体化团队内部。在整个服务架构的设计中，需要保持对开发者体验的关注。顺畅地将企业资源服务化，这是企业数字化旅程的第二步。

了解更多关于数字平台战略的信息，可下载《数字平台战略》白皮书。

更多精彩商业洞见，请关注微信公众号：ThoughtWorks商业洞见