独家系列：让我们遇见未来——为何在云平台中使用REST作为架构设计风格

在我们设计新一代企业云平台的时候，需要集成大量的、依赖不同开源项目的、来自不同业务领域、不同开发团队、甚至外部合作伙伴的服务，那么如何对这些服务做统一抽象呢？

我们的方案就是：一切皆为资源，灵感来源于Unix的理念——“一切皆为文件”。

Unix里，不光文件、目录、设备、socket这些东西都是文件，连api也在逐渐地文件化。甚至是关闭一个cpu核心这种很底层的操作，也可以通过类似文本编辑的操作来完成。

这种一致性的设计，降低了集成的整体复杂度，方便了微服务之间的集成以及上层业务的开发。Unix的哲学是至下而上，确实很好地对业务做了支撑，不过业务本身好不好，还要至上而下的智慧。

但是，只有一致性的设计还不够，这其中还要做到最小化的约束，比如对开发语言和工具链的约束，给开发人员尽量大的自由度。

就像是制造业的集成方式，才不会管你的产品是用什么工具、哪种生产线生产出来的。

满足这些要求的，就是REST设计风格。

超文本驱动，人和各种工具，都容易识别。接口统一为CRUD操作，避免了自定义接口操作带来的交互复杂性，另外还有可寻址、可外部负载均衡等好处。

REST是M2M的最佳集成方式，也是我们新一代数字化企业云平台的集成方式。

我们使用REST风格带来的优势如下：

最大的好处是工具链非常丰富，拿个浏览器装个插件也能玩，同时也遇到了一些挑战。

比如，有些开发人员没有从架构全局考虑，对把自己熟悉的技术实践转化为REST风格有所抵触。有些开发人员认为REST的CRUD操作太简单，无法描述复杂的企业业务。

有时候，我们会陷入格式细节的争论。比如，REST API的版本该如何描述，是http://server:port/api/v2/customers/123 还是 http://server:port/api/customer/123?version=2，或者放到Header里。一定还会有更多的挑战，需要在实践中慢慢摸索。

这是我们新一代数字化企业云平台的整体视图，微服务之间全部使用REST API连接。

（好了，先到这里，给大家留些时间泡杯JAVA~）

附： 各 群 答 疑

Q1、群友：最后微服务那张图片，没有看到服务注册、服务路由、熔断器、服务发现等，是不是普元的微服务架构更聚焦于业务层面的缘故？

答：所有都是微服务，所以才要一个统一的资源描述。那个图主要展现了业务层面，你说的当然也要有。以下为新一代的整体架构图：

我们希望把内部的组件、需求、设计等过程成果 业务服务都统一的作为资源。所以，在资源的描述上风格需要一致性的风格，rest解决了风格问题，但还是有非常多的细节。例如，微服务的数据完整性处理，就需要在rest表述出来。（普元CTO焦烈焱）

群友：但是get，put，post，delete并不能完整描述这个世界上所有的业务原义，这个怎么解决？

答：如果我们把一切看成资源的话，其实这几个语义足够了。在实践过程中，可以再分为资源和能力（API）两种具体对待。其实，最大的障碍来自我们自己RPC调用的思维太根深蒂固。刚才男总讲了，rest是机器 to 机器之间最好的沟通方式，那我们的设计就应该从机器的角度考虑，就比较容易克服RPC方式的影响了。（普元CTO焦烈焱）

Q2、群友：看到你们的架构总图，物联网设备这块儿存在一些实时的数据通讯，这样的业务场景，你们也用rest风格来描述吗？

答：这是个麻烦的问题，rest风格是http的最佳实践，而物联网这块是mqtp等协议，要转换。但是按照我们对rest的设计，他用来描述资源，对于物联网数据的流动，需要有一个在网关上的解耦，我们有个event hub在做这个事情。（普元CTO焦烈焱）

Q3、群友：这个微服务架构和普元现有esb产品是啥关系啊，如果都是restfulapi接口，是不是esb已out了？

答：不会。esb本身其中一个能力就是协议转换，试想，企业环境下你无法要求外购的软件都采用rest方式，就需要esb。另外，esb还会起到流量控制，服务转发作用，普元的esb在新一代云计算架构中，还是用来作为服务集成 对外网关的能力。esb还可以做为对外服务的网关，但对外服务平台的业务逻辑用微服务架构比较好。要在esb上扩展，例如oauth认证等，在我们一些客户里面有用。（普元CTO焦烈焱）

Q4、群友：接入安全这块能介绍一下吗？

答：接入安全包括：1. 我们公有云用了阿里云，这里用了VPC，同时通过自定义安全策略来做（对外服务开通EIP）；2. 协议安全，使用加密协议，这次是https，同时通过数字证书等加强能力；3. 管理安全，权限到rest资源和操作，token具有时效性。（普元云计算首席架构师顾伟）

Q5、群友：现在应用大多偏向于前后端分离，甚至有的时候前段也承担了一部分后端的能力，这方面是如何解决的？我觉得现在的编程风格中，前端与后端的边界越来越模糊了。

答：我们支持分离和合并两种部署模式（开发期分前端和后端组件），但前端一般不承担后端的能力，这是不合理的表现。前后端边界不应该模糊，现在前端、终端技术栈非常多，与后端分工和能力要求是区分很明显的。（普元云计算首席架构师顾伟）

Q6、群友：能否问一下，这个云平台中的服务发现是基于什么的？我们现在是基于zookeeper做的，策略是轮询，感觉不是很理想。

答：我们以前产品里用过zk，现在准备用etcd，客户端集群，策略可以自己定。为什么没有用起来，健康状况，负载情况都是客户端策略的依据。（普元云计算首席架构师顾伟）

关于作者：

宋潇男

EAII-企业架构创新研究院 专家委员

现任普元云计算架构师，曾任华为云计算产品技术总监。曾负责国家电网第一代云资源管理平台以及中国银联基于OpenStack的金融云的技术方案、架构设计和技术原型工作。

关于EAII

EAII（Enterprise Architecture Innovation Institute）企业架构创新研究院，是专注于企业架构与业务创新领域的研究机构，致力于金融、电信、能源与政务等行业领域的企业软件架构优化设计与 创新研究，以及分布式计算、服务构件技术、可视化技术、业务流程管理、内存计算、企业移动计算、数据治理等领域的技术研究。