分类:  Azure云架构师入门    ◆ 标签:  #Azure   #基础   #Azure Cloud Architecting   ◆ 发布于: 2023-06-05 11:40:15

什么是微服务？ 官方的定义就是微服务是一系列小的，自包含的服务构成的应用系统。实际远远不止这些，微服务虽然在解耦了服务之间的依赖关系，不再将更复杂的业务全部包含在某一个API中，但是这并不代表降低了业务的复杂性，恰恰相反，正是因为有了特别复杂的业务需求，我们才尝试使用类似于微服务这样的架构来解决我们的问题，一个非常有意思的问题是，同一个复杂的业务在很多时候看起来使用微服务架构反而是更复杂了，例如以前简单N层架构，如果一个业务有几个事务必须保证完成，使用N层架构，一个API中全部完成，可能就是慢一点，但是如果使用微服务，还得考虑分布式事务，或者事务补偿机制，总之还得拆分业务需求，看起来也不是那么美好。那么微服务到底适用于什么场景呢？

第一当然是很大的应用系统，第二是很大的机构或者团队，最容易体现特点的就是大字。

下图是微服务的一个图示:

微服务的特点：

• 具有规模小，独立，松散耦合的特点。
• 每个服务都是一个基本的代码，由小型的开发团队开发和管理，发布。
• 服务可以独立的部署，更新部署时不会影响到其他的服务。
• 每个服务负责保持自己的状态以及处理自己的数据。
• 服务之间的通讯通过API来进行通讯，不暴露内部实现。
• 编程模型可以多样化，例如不同的框架，不同的工具等等。

另外微服务还必须有配套的一些技术支持，例如强大的日志分析和查询系统，API网关，DevOps的理念等等。

主要优点

• 开发的敏捷性，这个是一个这些年推广的最大的一个开发理念了。快速开发，快速迭代，随时回滚。
• 小型团队，由于每个服务都是功能比较单一，所以对于开发人员的数量可以维持在一个较小的值上。
• 小型代码库。
• 混合技术，由于只需要暴露API, 内部实现是黑盒，因此可以采用多种的技术来实现。
• 错误隔离：每个服务都是单独的，一个服务crash，并不会影响其他服务的运行。
• 可伸缩性
• 数据隔离

可能遇到的问题

微服务代表着一个词：复杂！

• 复杂性，需要有详细的文档记录和描述每个服务的功能，依赖等等信息。
• 开发和测试
• 缺乏监管
• 网络拥堵和延迟，这个好理解，毕竟每个服务都是需要通过网络进行交互的。
• 数据的完整性
• 管理复杂。
• 版本控制。
• 技能要求高

所以微服务对于团队，对于业务，对于架构师，开发人员要求都很高。

最佳做法

• 围绕业务对服务建模。
• 分散所有资源。 单个团队负责设计和生成服务。 避免共享代码或数据架构。
• 拥有数据的服务应当有专用的数据存储。 为每个服务和数据类型使用最合适的存储。
• 服务通过设计完善的 API 进行通信。 避免泄露实现细节。 API 应对业务建模，而不是对服务的内部实现建模。
• 避免服务之间耦合。 耦合的原因包括共享的数据库架构和严格的通信协议。
• 将身份验证和 SSL 终止等跨领域操作分流到网关。
• 让网关不必了解业务。 网关应处理和路由客户端请求，而无需了解业务规则或域逻辑。 否则，网关会变成一个从属物，从而导致服务之间耦合。
• 服务应具有松散耦合和高功能内聚的特点。 应当将可能会一起更改的函数打包并部署在一起。 如果它们驻留在不同的服务中，这些服务最终会紧密耦合，因为一个服务中的更改将需要更新其他服务。 两个服务之间的通信过于频繁可能是紧密耦合和低内聚的征兆。
• 隔离故障。 使用复原策略可防止某个服务中的故障级联。 请参阅 复原模式 和 设计可靠的应用程序。