微服务体系架构浅谈

微服务体系结构描述了一种使用松散耦合服务集合开发应用程序的方法。以前，应用程序是基于集中式多层体系结构的。在大型机和台式机的时代，这种方法很有效。但在云计算和移动设备中，后端必须随时可用于各种设备。Bug修复和特性必须在不停机或不部署整个应用程序的情况下快速交付。

微服务是独立部署的，通过webapi或消息队列进行通信以响应传入事件。它们协同工作以提供各种功能，如用户界面前端、推荐、物流、计费等。

微服务通常在容器中运行。容器简化了微服务的部署，但即使没有容器，微服务也可以运行。

微服务是封装业务场景的自主独立服务。它包含 代码 和 状态 。通常，微服务甚至包含自己的数据存储。这使得它具有独立的可版本性、可扩展性和可部署性。微服务是松散耦合的，通过使用http等协议的定义良好的接口与其他微服务交互。它们在出现故障时 保持一致和可用 。微服务是可独立发布的。每个微服务都可以自己扩展，而不必扩展整个应用程序。

微服务有哪些类型？

大体上，有两种类型的微服务：

无状态：没有状态或者可以从外部存储（缓存/数据库）检索。它可以扩展而不影响状态。可以有N个实例。示例：web前端、协议网关等。无状态服务不是缓存或数据库。它经常访问元数据，没有实例关联，节点丢失不明显。

有状态：保持一个强硬、权威的状态。对于大型超规模应用程序，状态保持在接近计算的状态。N通过复制和本地持久性实现一致的拷贝。示例：数据库、文档、工作流、用户配置文件、购物车等。有状态服务由数据库和缓存组成，节点丢失是一个值得注意的事件。它有时是一个保存大量数据的自定义应用程序。

作为一种变体，一位作者确定了三种类型：无状态（计算）、持久性（存储）、聚合（编排）。聚合微服务依赖于其他微服务，因此具有网络和磁盘I/O依赖性。

当我们将微服务视为分层体系结构时，我们可以确定以下类型：

• 核心/原子服务 ：细粒度的自包含服务。没有外部服务依赖项。主要是业务逻辑。通常没有网络电话。
• 复合/集成服务 ：由多个核心服务组成的业务功能。包括业务逻辑和网络调用。实现路由、转换、编排、弹性和稳定性模式。通常与遗留或专有系统接口。
• API/Edge服务 ：一组选定的集成服务和核心服务，作为用户的托管API提供。实现路由、API版本控制、API安全和限制。

微服务与API有何不同？

API不是微服务，微服务也不是API的实现。API是一个接口。微服务是一个组件。术语“ micro ”指的是组件，而不是公开接口的粒度。微服务可用于公开一个或多个api。然而，并不是所有的微服务组件都公开api。

微服务架构和面向服务架构（SOA）之间的关系是什么？

SOA和微服务架构涉及不同的范围。SOA与企业服务公开相关，而微服务体系结构与应用程序体系结构相关。两者都试图实现许多相同的事情（将业务功能创建为独立组件），但规模不同。它们在可维护性、粒度、敏捷性等方面有所不同。SOA是一个非常宽泛的术语，微服务是该用法的一个子集。Netflix指出，微服务是“细粒度SOA”。微服务被认为是“SOA做得对”。

一些微服务原则与SOA有很大的不同：

1. 重用不是目标 ：由于通用组件所创建的依赖关系，不鼓励重用通用组件。最好通过复制重复使用。

2. 同步是不好的 ：进行诸如API或web服务之类的同步调用会创建实时依赖关系。微服务之间尽可能使用消息传递。

3. 运行时服务发现 ：假定组件是易失性的。因此，客户机通常有责任在实例之间找到甚至负载平衡。

4. 采用了数据复制技术 ：事件源等技术可以产生多个独立的数据“视图”，确保微服务真正解耦。

在设计微服务架构时，需要牢记哪些重要原则？

一般来说，在设计微服务体系结构时，以下原则是很好的：围绕业务领域建模、自动化文化、隐藏实现细节、高度可观察、分散所有内容、隔离故障、消费者优先、独立部署。

使用微服务架构有什么好处？

优势跨越开发和运营。简单地说，我们注意到以下优势：大规模构建和运营服务，提高资源利用率以降低成本，故障隔离，持续创新，小型专注团队，使用任何语言或框架。

可伸缩性来自于微服务支持的模块化。由于容器的存在，微服务在各种环境中的部署变得更加容易。由于服务的隔离，还有一个安全优势：对一个服务的攻击不会影响其他服务。

微服务是关于代码和开发的。容器是关于部署的。容器支持微服务。容器提供了隔离的环境，因此是部署微服务的理想选择。但是，可以在没有容器的情况下部署微服务。例如，可以在amazonec2上独立部署微服务。每个微服务都可以在自己的自动缩放组中独立缩放。

为什么我不应该为我的应用程序采用微服务呢？

由于应用程序是跨微服务分布的，这样的分布式系统更难管理和监视。操作复杂性随着微服务及其实例数量的增加而增加，特别是当它们被动态创建和销毁时。网络呼叫可能很慢，有时甚至会失败。 由于是分布式的，很难保持强一致性，应用程序必须确保最终的一致性。

微服务需要更多的时间来规划和划分应用程序。它们的设计应该考虑到失败。当您正在构建一个最小可行产品（MVP）或尝试评估什么是有效的或可以为业务增加价值的，那么单一的方法会更快更容易。只有当你的想法和商业价值被证明后需要扩展时，才采用微服务。

如果您管理的是一个遗留应用程序，那么迁移到微服务的工作可能需要相当大的成本。技术堆栈可能比单一应用程序大得多。应用程序对网络及其性能有很大的依赖性。微服务可以独立测试，但要测试整个应用程序更为困难。