目前用在软件交付的主流方法，是将整个应用程序构建，整体集成与测试。当出现无论多么小的修改，都需要回归一个完整的应用程序测试周期。而使用微服务，软件模块作为独立的运行时服务，本身具有良好定义的API。微服务方法可以更快地向应用程序传递较小的增量更改。
\
要成为微服务，服务必须是：
微服务设计规约：可扩展
微服务必须能够独立，与同一应用程序中的其它服务进行扩展，向上或向下扩展。
此约束表示可以根据负载或其他因素微调应用程序性能、可用性和资源使用情况。
此种约束可以通过不同的方式实现，以流行的系统构建方式，运行微服务的多个无状态实例，包含服务命名，注册和发现机制以及路由请求与负载均衡。
微服务设计规约：可伸缩
微服务在发生故障时不影响应用程序中的其他服务
可伸缩性，也称弹性。表示单个服务实例故障时，应该对应用程序的影响最少。
在微服务中，所有实例的失败应只影响应用程序的单一功能，用户能够继续使用应用程序的其它部分运行不会受到影响。
微服务是一个松散耦合的面向服务的体系结构，具有上下文与边界。具有弹性结构，与其他服务松散耦合，上下文限制服务出现失败之区域。
微服务设计规约-可组合
微服务必须提供统一的接口，且支持服务组合。
微服务的API有特殊的标识，用来表示和操作资源的常用方法，用以描述API模式和API操作支持。REST架构风格的“统一接口”约束也描述了这一方法。
服务组合是SOA的一种设计原则，具有明显的优点，但很少有资料说明如何实现的指导原则。微服务接口设计应该具备组合模式支持，如聚合，链接和更高级别的功能，如缓存，代理与网关。
微服务必须只含高内聚的实体
在软件中，衡量事物是否属于一体是一个重要指标。若模块中的对象和函数都集中在相同的任务上，则称该模块具有高内聚力。内聚力越高，软件越易维护。
微服务只执行单个业务功能，即它的全部组件都应具有高内聚性。这和面向对象设计的单一责任原则是一致的。
\
