微服务(Microservice)是一种构建风格。它可以用来开发一个由多个小型服务构成的应用程序。每个小的服务能够运行在它自己的进程里面， 而服务之间的通讯可以通过网络协议来实现 （比如说HTTP， 或者RPC）。由于每个微服务是独立的， 所以在开发和运维方面，微服务可以有独立的团队来进行管理，团队可以为此微服务选择技术栈 （开发语言， 数据库， 以及部署环境等）。这大大提高了开发的灵活性。

传统上，一个应用程序往往是把所有的服务放在一起的：这个程序的所有部分使用同样的语言，运行在同样的进程里，数据也储存在同样的数据库里。 当这个应用程序变得越来越大的时候， 整个程序变得难以管理和调试。 微服务的出现就是为了解决这个问题。它使得大的程序变成很多小的程序，易于开发，运维。可以加快开发的迭代时间。

优点：

• 把一个大的复杂的应用化解为多个小的应用
• 每个微服务可以被独立开发
• 每个微服务可以有自己的技术栈
• 每个微服务可以被独立部署
• 每个微服务可以独立的进行水平扩张或收缩(horizontal scale)

缺点：

• 在大型的服务里， 各种服务之间的通讯可以通过一个程序调用即可完成； 在微服务架构里，微服务之间需要通过网络协议进行通讯， 这降低了整个服务的性能。
• 微服务之间的依赖关系使得测试，容错处理(fault tolerance)，微服务间客户端发送的请求的度量追踪(request tracing)，日志管理等都带来的挑战。比如说服务A依赖于服务B，B依赖于服务C. 如果服务C出现问题（如崩溃或没有响应），如何处理B与A的响应？又比如当系统出现问题时， 如何快速找到问题是出现在哪个服务？

设计考量

与单一的大应用不同， 由于微服务的独立性， 每个微服务有自己的接口(API)，日志系统(Logging system)，度量系统(Metric system)和部署(Deployment)，所以在设计基于微服务的应用的时候要考虑下面几个方面。

• 每个微服务的接口的吞吐能力(throughput)， 是否应该设置一个上限
• 如何做好微服务日志管理和收集(Aggreation)。 日志的格式(structural logging)最好是有结构的。
• 如果某个服务出现问题如何处理。比如设置断路器(Circuit Breaker)，使其对异常情况能够有快速的反应。要知道用户在浏览网页的时候，网页没有响应是非常差的用户体验。
• 如何使微服务的节点时时了解到正在运行的相关节点(service discovery)。
• 如何时时监测每个微服务的度量(Metric)， 以保证它们在健康的状态下运行。