21CTO导读：微服务是一种新的软件架构与交付形式，其应用程序由几个小型运行时服务构成。
目前用在软件交付的主流方法，是将整个应用程序构建，整体集成与测试。当出现无论多么小的修改，都需要回归一个完整的应用程序测试周期。
而使用微服务，软件模块作为独立的运行时服务，本身具有良好定义的API。微服务方法可以更快地向应用程序传递较小的增量更改。
微服务架构需要考量与权衡以下几个因素：
1）微服务方法需要建立在软件设计，架构和DevOps风格组织的最佳实践与模式之上。
2）微服务需要分布式开发和架构方面的专业知识，并且要在没有适合工具的情况下实施，如果贸然改变架构，微服务可能成为组织的噩梦。
在本文的其余部分，为微服务架构风格定义五个架构约束（驱动所需属性之原则）。
要成为微服务，服务必须是：
可扩展
可伸缩
可组合
最小单元
完整性
图1 微服务架构示意图
微服务设计规约之一 ：可扩展
微服务必须能够独立，与同一应用程序中的其它服务进行扩展，向上或向下扩展。
此约束表示可以根据负载或其他因素微调应用程序性能、可用性和资源使用情况。
此种约束可以通过不同的方式实现，以流行的系统构建方式，运行微服务的多个无状态实例，包含服务命名，注册和发现机制以及路由请求与负载均衡。
微服务设计规约之二：可伸缩
微服务在发生故障时不影响应用程序中的其他服务
可伸缩性，也称弹性。表示单个服务实例故障时，应该对应用程序的影响最少。
在微服务中，所有实例的失败应只影响应用程序的单一功能，用户能够继续使用应用程序的其它部分运行不会受到影响。
微服务是一个松散耦合的面向服务的体系结构，具有上下文与边界。具有弹性结构，与其他服务松散耦合，上下文限制服务出现失败之区域。
微服务设计规约之三 - 可组合
微服务必须提供统一的接口，且支持服务组合。
微服务的API有特殊的标识，用来表示和操作资源的常用方法，用以描述API模式和API操作支持。REST架构风格的“统一接口”约束也描述了这一方法。
服务组合是SOA的一种设计原则，具有明显的优点，但很少有资料说明如何实现的指导原则。微服务接口设计应该具备组合模式支持，如聚合，链接和更高级别的功能，如缓存，代理与网关。
微服务必须只含高内聚的实体
在软件中，衡量事物是否属于一体是一个重要指标。若模块中的对象和函数都集中在相同的任务上，则称该模块具有高内聚力。内聚力越高，软件越易维护。
微服务只执行单个业务功能，即它的全部组件都应具有高内聚性。这和面向对象设计的单一责任原则是一致的。
微服务设计规约之五 - 完整性
微服务必须在功能上保证完整性
C ++的创建者Bjarne Stroustrup表示，良好的软件必须是“最小化但完整”，即尽可能小，并且不小。
与此类似，微服务提供完整的功能，与应用中的其他服务具有最小的依赖性（松散耦合）。
这很重要，否则就无法对各个服务进行版本管理和升级。该约规定了最小约束。放在微服务一起必须“最小但完整”。
设计微服务应用需要遵循应用程序模块化设计、面向服务体系结构的原则，以及设计模式及最佳实践。
在本文中，共描述了微服务的五个架构约束，这些约束可以帮助人们遵守微服务式架构的规则，以体现微服务的主要特性。
比如在微服务约束的第一点中，弹性能力实现将数据层与应用层分离，形成无状态的服务。
我们以顾问名义帮助某个团队构建了符合以上规则的解决方案，能够轻松部署和运行微服务应用。
以容器运行的微服务式应用程序将为下一代软件创新提供动力，如果你也正在使用微服务或对微服务感兴趣，欢迎在本文底部留言。
