上文我们提到，传统企业在逐步构建自己的数字化平台的过程中，需要重点关注交付基础设施、API和架构治理、数据自助服务、创新实验基础设施和监控等方面。系统和用户联系技术的五个支柱。今天我们就来聊一聊API、架构治理这些听起来很技术性的概念，和企业的数字化战略之间的关系。1、企业资源服务自20世纪90年代以来，企业资源规划（ERP）一直是企业信息化的核心问题。ERP植根于供应链管理，通过整合内部财务核算、制造、库存等信息流，提升企业的计划和控制能力。然而近年来，在互联网的冲击下，传统企业开始面临新的挑战。尤其是在互联网脱媒效应的影响下，原本在供应链上下游各司其职的企业，一下子被压缩到“生产-流通-消费”极其精简的价值链中。药品购销两票制就是这种极简价值模式的直观呈现。在这种模式下，拥有技术优势和消费者触达能力的互联网企业可能会形成支配性的超级垄断，排挤传统流通企业，将生产企业变成自己的代工生产商。竞争对手恐惧的来源。传统企业要想对抗互联网企业的竞争，最好的办法不是在互联网上肆意拼技术和流量，而是在自己擅长的领域进行斗争：将自己多年积累的线下资源转化为自己擅长的领域。融入线上服务，打造属于自己的产业线上生态圈，不仅支持公司线上运营，还为上下游周边企业提供线上运营平台，将线下优势转化为线上优势，以资源优势反制技术优势。为了支持企业资源的服务化，在设计在线服务的API和架构时需要考虑以下问题：平台架构和API的设计应关注开发者体验。API背后，应该从业务功能的角度划分合理的限界上下文和服务边界，对外提供高内聚低耦合的服务。在服务边界之间，应该考虑异步事件机制来实现服务之间的通信，以解耦领域模型，客观地描述需要长时间运行或本质上不可能立即完成的操作。为了便于使用，API网关应该作为所有服务用户的单一入口点提供，许多内部IT系统的复杂性应该在API网关后面处理。整个API架构应该以微服务的方式呈现，避免典型SOA架构中常见的过于复杂的ESB编排逻辑。ERP之后是什么？2010年代以来，“后ERP时代”一词不断被提起。谈到ERP的发展方向，通常会涉及到业务和技术两个角度。例如，一种观点认为，ERP需要从以流程为中心转变为以客户为中心，需要用好云计算、社交网络、大数据、移动化等新技术。ThoughtWorks认为，互联网时代ERP的发展方向将是企业资源服务化（ERS）。通过数字化平台的技术能力，可以将企业的资源整合到行业的互联网生态中，为企业铺设清晰的数字化路径。道路。2.API与架构治理的解读下面我们来详细了解一下在“API与架构治理”的帽子下需要考虑哪些具体问题。1.开发者体验当企业资源以服务的形式提供时，就意味着不可能像传统的IT系统建设那样，强制他人使用这些服务。尤其是如果我们想把这些服务提供给第三方开发者，希望他们可以开发出各种应用，那么服务的API的易用性将极大地影响到它能吸引多少第三方开发者。在讨论开发者体验时，可以从开发工具和开发环境的安装、配置、管理、使用和维护的角度来考虑。具体来说，开发环境和测试环境是否可以按需弹性获取，开发/测试基础设施和持续交付流水线是否以源代码的形式提供并完全自动化，是否对主流开源软件提供支持，是否对提供可编程的是否用户友好、命令行友好（不仅仅是图形）的工具界面、安全、数据访问权限和其他公司法规严重影响开发人员的效率和体验，这些都是影响开发人员体验的要素。2.服务边界与所有面向对象的设计一样，服务设计应该是高内聚和低耦合的：与业务相关的修改只在服务内部进行，服务的修改/部署不需要影响其他服务。与代码库内部的对象设计不同，每个服务通常都有自己的代码库，并由专人维护（而不是每个人都拥有所有代码），因此服务边界的变更会带来更大的变更成本。因此，服务边界的划分需要引起重视。在设计原则上，服务边界应该体现业务边界，而不是单纯从技术角度来划分服务边界。从业务功能的角度划分合理的限界上下文，基于领域模型和领域事件的聚合划分服务，更有可能得到与业务边界一致的服务边界。然后构建一个由业务目标驱动的全功能集成团队，让业务、技术和团队保持一致（康威定律再次起作用）。四色建模、事件风暴等方法可以有效实现领域驱动设计，从而建立良好的领域模型和服务边界。3、事件驱动架构采用异步事件机制实现服务间的通信。对于本质上不可能立即完成的长时间运行的操作（例如，涉及人工操作），使用异步通信是一个合理的选择。即使不考虑实时响应，事件驱动架构也表达了领域模型之间的松耦合关系：跨领域协作以事件而非方法调用的形式表达，系统追求最终一致性而非强一致性.这种结构准确地映射了现实世界中多个相关但独立的团队之间的协作关系，避免了对其他服务的响应速度或可靠性等服务质量指标的过度依赖，使服务在技术上真正独立。系统设计时，借助事件风暴的方法，通过领域事件确定聚合根，进而划分微服务的限界上下文。当发生跨越多个聚合根的事件时，自然可以将其实现为异步领域事件，从而获得与领域设计高度一致的实现。在实现事件驱动架构时，当然可以使用传统SOA架构中的消息中间件。但是在微服务架构中，业务逻辑存在于各个服务内部，没有庞大臃肿的ESB（这个问题后面会详细讨论），所以消息机制不需要强大的服务编排（orchestration）能力。像RabbitMQ这样的标准消息代理当然好，很多系统（比如Bahmni）采用更简单的方法：当领域事件发生时，以ATOM格式发布；其他关注特定领域事件的领域模型订阅特定的ATOM提要主题。这种基于HTTP的事件传播方式最大的优点就是简单，几乎不需要增加新的软件就可以实现。但是，该解决方案在低延迟场景中表现不佳。4、公共网关微服务提供的API粒度与客户端的要求不同，因此客户端往往一个请求需要多个服务；服务器和客户端之间可能需要进行通信协议转换；不同的客户端有不同的数据需求，比如浏览器客户端可能比手机客户端需要更多的信息；服务的终端信息（主机+端口）可能会发生变化；做一层门面封装，提供API网关作为所有服务用户的单一入口。API网关处理请求有两种方式：一种是直接代理/路由到合适的服务；另一种是将请求散开/分发到多个服务。API网关可以为不同的客户端提供不同的API，可以包含客户端的适配代码。横切需求（例如安全性）也可以在API网关中实现。当服务数量增加，API网关变大时，维护一个通用的API网关会增加API网关层的复杂度，导致出现独立的“API团队”，协调沟通的工作量也会增加。这时候可以考虑引入公共网关的一个变体：BackendForFrontend(BFF)，专为特定前端设计，即为每个前端应用提供单独的API网关，让对齐业务的集成团队可以完成前端和后端开发，而不必等待“API团队”完成他们的积压工作。API网关可以作为独立的服务器端应用程序实现，但代价是增加了一层复杂性（以及潜在的错误）。为了降低这个成本，可以考虑使用Zuul等工具来实现API网关。5、微服务SOA拓扑结构与传统的SOA架构相比，所谓“微服务”最大的特点可能就是没有重量级的ESB。重量级ESB有历史原因。2000年代业界刚开始采用SOA的时候，虽然很多企业把业务系统打包成web服务，但是IT团队的组织结构没有改变，仍然是一群人集中负责整个业务流程way—just系统集成的方式不再是直接方法调用，而是服务编排（orchestration）。原本存在于集成代码中的复杂逻辑现在被转移到ESB中。而这个“ESB团队”成为了IT交付的瓶颈：无论是发布事件的服务、消费事件的服务，还是编排逻辑本身的变化，与事件相关的变化都需要经过ESB团队。团队的积压堆积如山，不可能对每一个服务、每一个应用都提供快速响应。微服务架构更注重服务与业务的对齐。贝佐斯所说的“两个披萨团队”不仅负责一个IT系统的交付，还负责使用这个IT系统来支持一个企业的成功。为了让单个服务能够独立开发、独立部署、独立运行，这个团队应该能够在很大程度上控制自己的进度，而不是依赖于中心化的技术团队的进度。因此，微服务应该通过服务注册和发现机制获取自己需要的依赖服务，并判断是否直接调用或订阅依赖服务的事件。每个服务都包含其业务对应的复杂性，而不是集中整个系统的复杂性。关于ESB和编排逻辑。整个系统（以及团队的架构）的架构应该呈现为一些端到端的拉通和业务对齐的纵向服务，而不是一个覆盖所有业务的大型横切块（ESB）.3.小结为盘活企业线下资源，打造行业线上生态圈，IT需要一套行之有效的服务API和架构治理方式。首先从领域驱动设计入手，合理划分限界上下文和服务边界，然后使用异步消息机制来描述领域事件。设计好的服务通过API网关或BFF暴露给前端应用，依赖和集成逻辑约束在与业务对齐的集成团队内。在整个服务架构的设计中，需要保持对开发者体验的关注。顺利服务企业资源是企业数字化之旅的第二步。【本文为专栏作者“ThoughtWorks”原创稿件，微信公众号：Thinkworker，转载请联系原作者】点此查看该作者更多好文
