什么是微服务？
Martin Fowler：简而言之，微服务架构风格这种开发方法，是以开发一种小型服务的方式来开发一个独立的应用系统。其中每一个小型服务都运行在自己的进程中，并经常采用HTTP资源API这样的轻量的机制来互相通信。这些服务围绕业务功能进行构建，并能通过全自动的部署机制来进行独立部署。这些微服务可以使用不同的语言来编写，并且可以使用不同的数据存储技术。对这些微服务我们仅做最低限度的集中管理。
微服务架构是一种架构模式，它提倡将单一应用程序划分成一组小的服务，服务之间互相协调、互相配合，为用户提供最中价值。每个服务运行在其独立的进程中，服务于服务之间采用轻量级的通信机制互相沟通（通常是基于HTTP的RESTful API）。每个服务都围绕着具体业务进行构建，并且能够被独立的部署到生产环境，类生产环境等。另外，应尽量避免统一的、集中式的服务管理机制，对具体的一个服务而言，应根据业务上下文，选择合适的语言、工具对其进行构建。
微服务是一种架构风格，一个大型复杂如阿健应用由一个或多个微服务组成。系统中的各个微服务可被独立部署，各个微服务之间是松耦合的。每个微服务仅关注于完成一件任务并很好地完成该任务。在所有情况下，每个任务代表着一个小的业务能力.
SOA和Microservices的区别
| SOA(SERVICE-ORIENTED ARCHITECTURE) | MICROSERVICES ARTICTURE |
|---|---|
| 最大化应用程序的服务可重用性 | 关注点是程序的解偶性 |
| 一个系统的修改需要修改整个项目 | 一个系统的修改只需要创建一个新的服务 |
| 开发运维和持续交付已经很流行，但是不是主流 | 主要关注点是开发运维和持续交付 |
| 主要关注业务方法的重用 | 更重要的概念是“上下文边界” |
| 它的通信使用的是企业服务总线（ESB） | 对于通信使用简单的消息传递系统 |
| 提供多种消息协议 | 使用轻量级的协议例如HTTP、REST或Thrift APIS |
| 所有的服务都部署在同一个平台上 | 应用服务器并没有真正的被使用，一般使用的都是云平台 |
| 很少使用容器（例如Docker） | 容器和微服务配合的非常好 |
| SOA服务共享数据存储 | 每一个服务都有自己单独的数据存储 |
| 共同的治理和标准 | 分开治理，更多关注团队的协作和选择的自由 |
详细说明区别
-
开发方面：这两个框架都是可以通过不同的编程语言开发工具来发布服务，它能够给开发项目团队带来多种多样的技术。开发需要多个项目组协调，然而使用SOA的话，每一个项目组都需要了解共同的通讯机制。然后另一个方面，使用微服务每一个服务都能够独立操作和单独部署。因此，频繁的发布微服务的新版本或者独立的扩展服务会变得更加容易。
-
“Bounded Context”: SOA鼓励组件共享，然而微服务却尝试最小化共享通过“bounded context”. 上下文边界能够使组件和数据偶合为具有最小依赖关系的单个单元。由于SOA依赖于多个服务来实现业务请求，系统使用SOA构建的系统好像比微服务更慢。
-
通讯：在SOA中，ESB可能成为影响整个系统的单点故障。每一个服务都是通过ESB通讯的，如果这些服务中的一个慢了，这些服务的请求就会阻塞在ESB中。另一个方面来说，微服务在容错方面要好得多。例如，如果一个微服务有内存故障，那么只有这个微服务会受到影响。所有其他微服务将继续处理请求。
-
互用性：SOA通过其消息传递中间件组件促进了多种异构协议的使用。微服务试图通过减少集成选择的数量来简化体系结构模式。因此，如果您希望在异构环境中使用不同的协议集成多个系统，则需要考虑SOA。如果所有的服务都可以通过相同的远程协议访问，那么微服务对你来说是一个更好的选择。
-
大小：最后但同样重要，SOA和微服务的主要不同是大小和范围。微服务中的前缀“微”指的是内部组件的粒度，这意味着它们必须比SOA的粒度要小得多。微服务组件通常只做一件事情做好。另一方面，SOA服务通常包含很多的业务功能，他们经常作为子系统实现。
我们不能简单的说哪个架构比哪个架构更好，这主要取决于你的应用系统的构建目的。SOA适合构建大型应用，复杂的企业应用化境，需要结合其他一些应用。也就是说小应用不是很适合使用SOA，因为没有一个中间组件。另一方面微服务适合构建小的套件或者是web基础系统。所以，如果你是开发一个手机或者是web应用，作为程序员来说微服务更容易控制。
