微软关于微服务体系结构的理解 _微服务

本篇文章转自微软官网技术文档。设计原则，优缺点等都总结的很好，非常值得阅读收藏，欢迎关注我。

微服务体系结构由一系列小型的自治服务组成。每个服务都是自包含服务，并且应实现单个业务功能。

文章插图

在某些方面，微服务是面向服务的体系结构 (SOA) 的自然演变，但微服务与 SOA 之间也存在一些差异。下面是微服务的一些典型特征：

在微服务体系结构中，服务具有规模小、独立和松散耦合的特点。
每个服务都是一个单独的基本代码，可由小型开发团队管理。
服务可独立部署。团队可以更新现有服务，而无需重新生成和重新部署整个应用程序。
服务负责暂留自己的数据或外部状态。这一点与传统模型不同，后者由单独的数据层处理数据暂留。
服务通过定义完善的 API 相互通信。每个服务的内部实现细节均对其他服务隐藏。
服务无需共享相同的技术堆栈、库或框架。

除了服务本身，典型微服务体系结构中还会出现其他组件：
管理。管理组件负责将服务放置在节点上、标识故障、跨节点重新平衡服务等等。
服务发现。维护一个包含服务及其所在节点的列表。支持使用服务查找功能查找服务的终结点。
API 网关。API 网关是客户端的入口点。客户端不直接调用服务，而是调用 API 网关，网关再将调用转发到后端上的相应服务。API 网关可以聚合来自多个服务的响应，并返回聚合的响应。
使用 API 网关的优点如下：

它分离了客户端与服务。无需更新所有客户端，便可对服务进行版本控制或重构。
服务可以使用对 Web 不友好的消息传递协议，比如 AMQP 。
API 网关可执行身份验证、日志记录、SSL 终止和负载均衡等其他跨领域功能。

何时使用此架构请对以下情况考虑使用此体系结构样式：

需要较高发布速度的大型应用程序。
需要高度可缩放的复杂应用程序。
具有大量域或多个子域的应用程序。
由小型开发团队组成的组织。

优点

独立部署。无需重新部署整个应用程序便可更新服务，出现问题时可回滚或前滚更新。Bug 修复和功能发布更易管理，风险更低。
独立开发。单个开发团队便可生成、测试和部署服务，从而推动持续创新，加快发布节奏。
小型专属团队。团队可专注于一个服务。缩小每个服务的范围后，基本代码变得更好理解，新的团队成员也能更快上手。
错误隔离。某个服务中断不会影响整个应用程序。但是，这并不意味着用户可以无偿复原。用户仍需遵循复原最佳做法和设计模式。请参阅设计可靠的 Azure 应用程序。
混合技术堆栈。团队可选取最适合其服务的技术。
精细缩放。服务可独立缩放。与此同时，每个 VM 的较高服务密度也意味着 VM 资源得到充分利用。使用放置约束，可将服务与 VM 配置文件（高 CPU、高内存等等）匹配。

挑战