知识分享

创建使用服务的应用这一理念一直具有吸引力。在整合通过标准API引接相同服务的多个应用时，为什么要从新开始编写代码呢？只要这些服务被正确提供，我们就能够享受到规模经济所具有的巨大优势。

　　过去，对这一理念的尝试在过度设计(尤其是CORBA 和 SOA的不断发展)的重压之下一直没能取得成功。可通过API访问的小型单一用途程序，即微服务的最大吸引力之一是它们的使用一直都很平民化，并被开发者们所广为接受。如今这一服务方式已经站稳了脚跟。

　　Stefan Borsje是Wi-Fi热点设备销售公司Karma的联合创始人兼首席技术官。阅读一下他在2014所写的博文，我们会发现一个活生生的微服务典型范例。据Borsje称，由于开发网上商店的缘故，他的开发团队选择了微服务。

　　我们从后端一个大型应用着手将它们分解成具有意义的众多小应用。通过不断地创建应用，我们开始清楚自己正在尝试解决的问题，并且变得对这一问题越来越熟悉，问题的根源在于我们需要在应用不同方面之间确立一个边界。每当我们遇到应当分解为独立小应用的问题时，我们就会将它们变成一个服务。起初，这些小应用相对来说还是很大，但是随着微服务的不断部署，我们发现这些小应用能够变得更小。

　　例如，一个庞大的应用最初有一个“仓储”组件，但是Borsje的团队将其解决成为订单处理、执行和跟踪服务。甚至连面向公众的前端也被分解为多个服务。Borsje称，将大功能分解成独立服务能够大幅提升生产效率。这在某种程度上是因为开发人员不需要庞大应用在工作中方方面面都保持着关联性。

　　对Karma来说，微服务最大问题是其还处于测试当中。正如Borsje所说，“行动和最终结果相距较远，难以准确的找到因果关系。整个链条中可能会出现问题，但是到底在链条中的哪个环节出问题了呢？”

　　《敏捷宣言》一书的合著者Martin Fowler在去年3月份收集了人们喜爱微服务的原因。在11月份，Fowler通过幻灯片较为详细的阐述了多层解决方案和微服务测试。毫不奇怪，他支持单个服务的单元测试，并且承认这还不足以确认整个系统是否正在正常工作。他列出了一系列整合、分组、收缩和端对端测试策略，这些能够帮助开发者仔细思索微服务所存在的棘手问题。

　　另一个问题是：我们无法预测微服务在特定环境中是否能够满足需求。这也是为什么Karma将其电子商务平台部署在AWS(亚马逊网络服务)之上的原因。因为AWS能够自动扩展以确保在需求增加的情况下没有服务成为瓶颈。需要指出的是，微服务的典型代表Netfilx也在使用AWS。换句话说，微服务和云具有紧密的联系。理论上，我们能够使用VMware或OpenStack创建具有自动扩展功能的私有云，但是现实中难以实现，这也是公有云胜出的原因。

　　另一个以微服务为基础的最新技术是Docker，其能够将应用打包并将它们部署在Linux容器中。事实证明，微服务和Docker之间配合默契，这也是为什么所有的大型公有云目前都支持Docker的原因。

　　显然，没有人可以保证微服务能够解决所有的问题。但是在其它基于服务的解决方案失败的地方，微服务架构可能会取得成功，因为它们是自下而上的，开发者能够决定服务类型和它们的大小。随着大型企业逐步接受微服务，团队能够决定哪些服务适合整个企业。

　　这类特殊扩展组件不适用于老式的硬连接基础设施。同样重要的是，开发者们之间的协作正越来越默契，并且逐渐成为了一种文化。这种文化使得开发者们会有组织的创建软件架构，而不是自上而下通过法令的方式强制他们这么做。

　　据说许多机构的开发者已经在管理部门知情或不知情的情况下开始使用微服务架构。无论是公有云还是私有云，只要借助于合适的云基础设施， 微服务架构不仅能够提升开发者的开发效率，还能够帮助开发者们开发出以往不可能开发出来的新应用。