# 维基百科微服务

微服务是一种软件开发技术 - 面向服务架构（SOA）架构风格的变种，它将应用程序分解为松散耦合服务的集合。**在微服务架构中，服务是细粒度的，协议是轻量级的。**将应用程序分解为不同的较小服务的好处是它可以提高模块性。这使得应用程序更易于理解，开发，测试，并且对架构变得更具弹性，可伸缩。它通过使小型自治团队能够独立开发，部署和扩展各自的服务来实现开发的并行化。它还允许通过连续重构来显示单个服务的体系结构。基于微服务的架构支持持续交付和部署。

## 特性

* Per Martin Fowler和其他专家认为，微服务架构（MSA）中的服务通常是通过网络进行通信以使用与HTTP等技术无关的协议实现目标的过程。
* 微服务架构中的服务可独立部署。
* 服务以细粒度的业务能力为基础。**微服务的粒度很重要 - 因为这是这种方法与SOA不同的关键。微服务强调的是细粒度，而SOA则强调的是粗粒度。**
* 服务可以使用不同的编程语言，数据库，硬件和软件环境来实现，具体取决于最适合的。这并不意味着单个微服务是用混杂的编程语言编写的。虽然几乎可以肯定的是，服务组成的不同组件将需要不同的语言或API（例如，Web服务器层可能使用Java或Javascript，但数据库可能使用SQL与RDBMS进行通信），这实际上反映了与整体式建筑风格的比较。如果将整体应用程序重新实现为一组微服务，那么各个服务可以选择自己的实现语言。因此，一个微服务可以为Web层选择Java，而另一个微服务可以选择基于Node.js的实现，但在每个微服务组件中，实现语言将是统一的。
* 服务规模小，启用消息，受上下文限制，自主开发，可独立部署，分散，并通过自动化流程构建和发布。

## 质疑

微服务方法受到许多问题的批评：

* 服务形成信息障碍。
* 与整个服务流程中的进程内调用相比，网络上的服务间调用在网络延迟和消息处理时间方面的成本更高。
* **测试和部署更加复杂**。
* 在服务之间转移责任更加困难。它可能涉及不同团队之间的沟通，用另一种语言重写功能或将其融入不同的基础设施。
* 当内部模块化的替代方案可能导致更简单的设计时，将服务的大小视为主要的结构化机制可能会导致太多的服务。
* 在基于微服务的体系结构中，**两阶段提交被视为一种反模式**，因为这会导致事务中所有参与者的耦合更加紧密。然而，缺乏这种技术会导致尴尬的情况，为了保持数据的一致性，所有事务参与者都必须实现这些要求。
* 如果使用不同的工具和技术构建，许多服务的开发和支持将更具挑战性 - 如果工程师经常在项目之间移动，这尤其是一个问题。

## 参考资料

[维基百科](https://en.wikipedia.org/wiki/Microservices)