微服务开发的5个绝佳实践
极客时间编辑部
讲述：初明明大小：4.53M时长：04:56
微服务架构的诞生解决了很多问题，它可以为不同的问题提供不同的解决方案。但正确设计微服务架构非常具有挑战性和困难，如果选择了错误的解决方案，那么微服务架构就是一个注定要爆炸的定时炸弹。最近，软件架构师卡马鲁扎曼（Md Kamaruzzaman）提出了一些微服务开发的最佳实践，这些实践将有助于开发有效的微服务应用程序。以下为重点内容。
1. 领域驱动设计
开发微服务的首要挑战是将大型、复杂的应用程序分割成小型、自主、独立的可部署模块。如果微服务没有以正确的方式进行分割，将会出现紧耦合的微服务，这些微服务将具有单体架构的所有缺点和分布式单体架构的所有复杂性。
幸运的是，已经有一个解决方案可以在这方面提供很大的帮助。艾瑞克·伊文思（Eric Evans）之前是一名软件工程顾问，他在不同公司的业务应用程序中遇到了关于软件复杂性的反复问题，于是，他将解决问题的见解和方法总结成了一本书，也就是《领域驱动设计：处理软件核心的复杂性》。伊文思在这本书中提出了三个核心概念：
软件开发团队应该与业务部门或领域专家密切合作。
架构师 / 开发人员和领域专家应该首先进行战略设计：找到有界的上下文和相关的核心域以及普遍存在的语言、子域、上下文映射。
架构师 / 开发人员应该进行战术设计，将核心域分解为细粒度的构建块：实体、值对象、聚合、聚合根。
2. 每个微服务都有自己的数据库
在将复杂的应用程序拆分为多个微服务模块之后，下一个挑战出现了，如何处理数据库？是否应该在微服务之间共享数据库？答案是把双刃剑。一方面，在微服务之间共享数据库将导致微服务之间的强耦合，这与微服务架构的目标正好相反，还会提升管理数据库事务的复杂性。另一方面，如果每个微服务都有自己的数据库或私有表，那么在微服务之间交换数据就打开了挑战的“潘多拉盒子”。因此，许多著名的软件工程师都提倡在微服务之间共享数据库，将其作为一种实用的解决方案。然而，微服务是可持续的软件开发。因此，每个微服务都应该有自己的数据库或私有表。
3. 持续交付
微服务架构的关键卖点之一是每个微服务都可以独立部署。如果你的系统包含了 100 个微服务，你只需要更改其中的一个，那么你就可以只更新那个微服务，而不需要修改其余的 99 个。
但在没有自动化的情况下独立部署 100 个微服务是一项艰巨的任务，所以要充分利用微服务的这一特性，结合 CI/CD 和 DevOps 实现自动化。
4. 异步通信
微服务架构中最具挑战性的设计决策之一是服务之间如何通信和共享数据。当每个微服务都有自己的数据存储时，这一点就更为重要了。通常，一个微服务可以单独存在，但是它不能单独实现所有的业务目标。所有微服务为了实现业务目标而在一起工作，为了在一起工作，它们需要交换数据或触发其他微服务来执行任务。
在微服务之间进行通信的最简单和最常见的方式是利用同步的 REST API，这是一种实用但临时的解决方案。如果服务 A 同步调用服务 B，服务 B 同步调用服务 C，服务 C 同步调用服务 D，那么延迟就会增加。此外，由于微服务主要是分布式系统，它们有可能会失败。通常，同步微服务会导致级联失败，即一个服务的失败会导致其他服务的失败。微服务之间的同步通信也导致了微服务之间的紧密耦合。因此，对于长期解决方案，微服务应该异步通信。微服务之间的异步通信有很多方式，可以通过消息队列，例如 Kafka，也可以通过异步的 REST （ATOM）或 CQRS。
5. 基础设施优于类库
在微服务软件开发的早期，Netflix 主要使用 Java 编程来开发微服务，他们还开发了许多类库。许多公司通过 Netflix 跟进并开始使用 Netflix OSS。后来，许多公司（包括 Netflix）发现，Java 实际上并不是开发微服务的语言，因为它体积庞大，而且冷启动问题严重。Netflix 后来转向 Polyglot 微服务范式，并决定不再进一步开发 Netflix OSS，这导致了追随者公司陷入困境。因此，与其大量投资于特定语言的类库（如基于 Java 的 Netflix OSS），不如使用框架，如服务网格、API 网关。
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线笔记
复制
AI
- 深入了解
- 翻译
- 解释
- 总结
该免费文章来自《极客视点》，如需阅读全部文章，
请先领取课程
请先领取课程
免费领取
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
登录 后留言
全部留言(1)
- 最新
- 精选
唐村仕子玩不起来，还是先把SOA用用好吧，服务化改造之路必须走！
收起评论