微服务的设计与架构

标准现在

要探讨设计在软件中的作用，可以考虑另外两个同样依赖它的领域：艺术和architecture。与艺术一样，许多软件设计可能只是品味问题。正如艺术界一样，在软件设计领域内引发激烈争论的问题，在其内部边界内反响最为强烈，而在这些边界之外则不一定产生多大影响。

设计在建筑中同样重要，无论是出于美学考虑还是物理上的重要因素。就像建筑物的结构一样，建筑设计会对软件的可靠性、鲁棒性和适用性产生重大影响。与建筑师类似，开发者通常也意识到软件内部结构元素的重要性，并会研究和讨论选择某种方法而非另一种方法在性能和业务方面的理由。

人们不希望使用一个per‐的计划个人住宅无法用来建造更大的结构，例如体育场馆、音乐厅或高层建筑。同样，软件中架构设计模式的选择必须根据预期的应用、工作负载和使用程度进行调整。

美学和用户反应在所有这些场景中都至关重要。在当前阶段，所有厂商的产品往往都经过精心设计，因此毫无疑问，在软件设计中必须高度重视用户体验和易用性问题。正如我们欣赏设计精美且功能完善的建筑一样，当软件设计既实用又具有艺术性时，使用起来才最为愉悦。

微服务架构

本期杂志的其他部分已广泛讨论了与微服务相关的概念。这些概念在某种程度上可谓新瓶装旧酒。通过编程接口实现服务功能分离的基本方法已经存在一段时间了。在面向服务的架构(SOA)框架内实现这种分离的方法也并非新鲜事物。

然而，微服务在云环境中的最新实现将面向服务的架构（SOA）理念推向了新的高度，其推动力来自于对快速、可互换、易于适应和易于扩展的组件的追求。这显然并非使用云计算的唯一方式，但它充分借鉴了云计算的基本功能特性，并与相应的交付框架高度契合。持续强调使用RESTful API（如之前的“标准现在”专栏中所讨论的）也加速了云服务交付的变革步伐和整体效用。

工作负载的分解以及微服务的渐进式可扩展特性，为面向服务的架构摆脱过去僵化、过于正式的实现方式提供了多种途径，并使其能够以更为简便的方式实施。这一演进的结果之一是新架构模式的发展，以及相应标准的出现和使用。

与艺术和建筑一样，在微服务交付中，设计者拥有很大的自主权。你可能会认为在快速变化的环境中，标准并不重要，或重要性较低微服务领域，但正如我将要展示的，这种假设并不正确。在很大程度上，现代微服务架构方法的灵活性和易于实现性，要么与成功的设计模式相兼容，要么实际上正是由这些正在成为标准的设计模式所推动的。

使用容器的微服务交付

将云设计中的不同趋势等同起来同样是不正确的。例如，当前在软件容器环境中实现不同软件集的倾向，更多是一种巧合，而非微服务设计的直接结果。

确实，容器可以实现彼此隔离的执行环境，并且由于能够按需快速实例化这些容器，因而具有良好的可扩展性。

软件容器的其他功能在克服时需要做更多的工作，例如需要提供周密考虑的机制来实现它们之间的网络通信，以及在不同物理主机或位于不同数据中心的主机上使用时所带来的相关复杂性。

类似在安全性、监控以及需要最小化容器的运行规模方面会出现问题。这些问题需要仔细考虑，并关注与微服务自身面向服务架构方面无直接关联的细节。

尽管存在这些缺点，微服务交付在许多方面与软件容器中的部署非常契合。事实上，这种方法目前是部署微服务最流行的方式，但要有效应对上述由此带来的复杂性问题，就必须使用标准。

本专栏已多次报道该领域内此类标准的出现，最早始于由CoreOS开发的appc应用容器规范，以及由Docker开发的runC容器引擎。社区投入了大量工作，将这两套规范的方法进行整合，并将其扩展至更新、更广泛的使用场景。

Linux基金会的两个当前相关项目是开放容器计划（www.open‐containers.org）和云原生计算基金会（CNCF，https://cncf.io）。流行的镜像格式包括ACI（在appc规范中定义的容器镜像格式）以及OCI（开放容器镜像格式规范）。CNCF内部开展的许多工作集中在软件栈的更高层次，旨在解决微服务分布式系统的大规模行为问题。

尽管这些组织仍在对各项标准的各个方面及其相互关系进行持续完善，但令人鼓舞的是，此类努力正从社区的持续关注中自然涌现。

数据格式和应用程序编程接口

为了让微服务架构在实践中发挥作用，必须将信息传入和传出这些服务，并找到在组件边界处实现信息交换和控制传递功能的方法。因此，程序员必须解决与数据交换和消息传递相关的设计主题，并通过合适的编排和控制来实现这些服务。

标准为这种数据交换提供了基础。云计算中最流行的数据格式是JavaScript对象表示法（JSON）和XML。JSON在两个标准中进行了规定：Ecma国际组织的ECMA‐404和互联网工程任务组的RFC 7159。XML是一种相对较早但仍然流行的基于文本的格式，由多个W3C标准支持，用于数据交换。

尽管它不如JSON人类可读，但每种格式都有其特定的优缺点，目前两者都仍在广泛使用。

对于物联网（IoT）和面向传感器的应用场景，如上一期关于制造业所讨论的，传感器网络对象表示法（SNON，www.snon.org）是一种基于JSON的表示方法，包含一些预定义字段，特别适用于处理传感器数据。此外，对象管理组织专门开发了数据分发服务（DDS，http://www.omg.org/spec/DDS）和DDS数据本地重建层（DDS‐DLRL）规范，以应对与物联网系统相关的数据交换任务。

与其他我提到的协议不同，DDS能够在标准集自身定义的方法内处理内容感知的网络路由、通过传输优先级进行数据优先级划分，以及单播和多播通信。

此外，通用数据标准可用于处理各种各样的数据集格式，而无需被锁定在特定格式中。例如，开放网格论坛与美国国家超级计算应用中心（NCSA，http://www.ncsa.illinois.edu）和IBM合作，开发了一种用于描述数据格式结构的语言，而无需重写这些格式。由此产生的数据格式描述语言（DFDL，www.ogf.org/dfdl）是一组灵活、通用的规范，适用于各种各样的数据输入、输出和格式转换问题，并且得到了商业和开源软件实现工具的支持。

当前在微服务中使用的许多方法会为访问特定数据创建自定义API。这种方法虽然通常在没有参考外部数据标准的情况下实现，但与之兼容。

因此，当前的云微服务设计背负着大量且多样化的API定义。

在之前的专栏中，我曾提到由网站ProgrammableWeb.com维护的API目录，截至撰写本文时，该目录收录了超过15000个API（www.programmableweb.com/apis/directory）。

这种情况要求应用程序编程接口的设计要么适用于应用领域中的较小子集，且在该子集中API保持稳定，要么按照通用的自描述或标准化模式进行构建。

有效的API标准示例包括RESTful API标记语言（RAML，http://raml.org）和Swagger，后者已发展为开放API倡议（https://openapis.org），如之前专栏中所讨论的那样。

消息标准

在了解用于数据交换的数据格式和应用程序编程接口之后，下一步是转向消息传递和应用控制。HTTP及其安全变体HTTPS是最熟悉的消息标准，并在工作小组网站（httpwg.org/specs）汇总的互联网工程任务组文档中进行了规定。

传输控制协议背后的互联网工程任务组规范构成了大部分互联网流量的基础。由于传输控制协议在各种环境中的重要性，社区继续对其给予密切关注。最重要的传输控制协议规范及其相互关系在RFC 7414中进行了总结。许多其他应用、传输互联网和链路层协议也很有用。用户数据报协议（UDP）适用于可以间歇性传输或不必始终完全接收的互联网通信。在无需握手和对单个消息包进行接收确认的情况下，可以使用UDP来执行IP通信。流控制传输协议（SCTP）为流媒体应用场景提供了传输控制协议（TCP）和UDP之外的另一种选择。

另一个与制造业相关的专用传输标准的例子是受限应用协议（CoAP）。根据其描述，“CoAP在应用端点之间提供请求/响应交互模型，支持服务和资源的内置发现，并包含Web的关键概念，如统一资源标识符（URI）和互联网媒体类型。CoAP旨在轻松与HTTP进行对接，以实现与Web的集成，同时满足受限环境中的特殊需求，例如支持多播、极低开销和简洁性。”

可扩展消息处理与存在协议（XMPP）是一种基于XML的通信标准，专为面向消息的中间件通信而设计。XMPP的核心规范是RFC6120, 6121,和RFC7622，其中包括在RFC 7395中定义的WebSocket绑定。除了基础规范外，专用XMPP组织还支持多种扩展（参见http://xmpp.org/extensions）。除了应用于人类通信之外，XMPP还被用于智能电网应用以及多种工业场景。2015年底，发布了多个面向物联网（IoT）应用场景的扩展。

与协议相比，用于高速机器对机器通信的发布/订阅消息处理方法可能具有优势。由结构化信息标准促进组织（OASIS）最近标准化的消息队列遥测传输（MQTT，http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/os/mqtt-v3.1.1-os.html）就是此类方法的另一个示例。

高级消息队列协议（AMQP）是另一种流行的中间件消息传递标准集，可通过发布/订阅或点对点通信模式进行应用。OASIS于2014年将AMQP发布为一系列标准（www.oasis-open.org/standards#amqpv1.0），并在同年晚些时候被国际标准化组织/国际电工委员会（ISO/IEC）联合采纳。AMQP采用分层架构，其规范集按该架构划分为不同的部分。

网络考虑因素

网络提供了将所有云服务相互连接的核心功能。我在本期杂志2016年5月/6月刊中对此主题进行了广泛讨论。指出：“云计算的基础在于，那些原本互不相连、高度扩展且快速变化的服务组件集合，能够被迅速而灵活地实例化并连接在一起，从而构成云服务的基础。”

性能需求在微服务架构的实现中尤为重要。这一考虑显然对单个服务组件在信息交换和功能方面的可缩小程度提供了实际限制。与安全性、微服务组件之间的连接性以及可扩展性相关的问题，也受到网络架构和协议选择的影响。

美国国家标准与技术研究院的一份草案出版物涵盖了这一主题，重点是安全性考虑。尽管该特定草案的意见征集期已经结束，但鉴于该主题的普遍性，我认为随着微服务交付领域的逐步成熟，本文讨论的问题在不久的将来可能会被多次重新审视。

与网络相关的特殊考虑也在推动一些微服务框架朝着远离数据交换的可读性、甚至远离API调用和消息传递中使用的线上传输协议的人类可读性的方向发展。我此前在往期讨论过的一些案例仍在不断成熟，包括谷歌在经过长期开发后近期发布了其gRPC框架的1.0版本（https://github.com/grpc/grpc/releases/tag/v1.0.0），并已提供多种语言绑定。

gRPC背后的设计方法广泛使用了协议缓冲区（https://developers.google.com/protocol-buffers/docs/reference/overview），这是一种旨在以比XML更简单的方式序列化结构化数据的设计结构，同时避免了JSON的一些局限性，并且设计上兼容HTTP/2。我个人认为，这些发展表明云服务正在出现新的设计趋势，即优先考虑交换的数据和API调用的速度和响应能力，而非人类可读性，这可能会在未来导致对支配微服务的一些基本假设进行根本性的修订。

总结与展望

此处的讨论主要集中在微服务的设计和建筑。我已经涵盖了与容器中微服务的打包和交付、数据交换、数据格式、消息传递和网络相关的考虑，重点关注这些领域与标准相关的最新主题。

我的下一篇文章将探讨与微服务编排相关的主题，包括《云应用拓扑与编排规范》（Tosca）和平台云应用管理（CAMP）等相关标准；微服务控制，包括开放云计算接口（OCCI）和云基础设施管理接口（CIMI）标准集；以及无服务器微服务，例如亚马逊Lambda及相关概念。我还将再次审视微服务架构的面向服务的架构（SOA）基础，以将这两篇文章的内容联系起来。

一如既往，本讨论仅代表我自己的观点。我希望听到您在此领域的意见和经验。我相信杂志的其他读者也会非常感谢有关此主题的更多信息。

请就本期或之前的专栏内容提出您的反馈意见。欢迎提供您认为业界应了解的有关云标准、合规性或相关领域的新闻。我乐意审阅可能投稿至本杂志的文章创意，或受邀撰写的专栏文章建议。您可通过alan.sill@standards-now.org与我联系。