微服务失败的八个常见原因（上）
极客时间编辑部
讲述：初明明大小：3.72M时长：04:04
微服务是当前流行的架构。简单地说，微服务就是一种面向服务的软件架构，在这种架构中，服务器端应用程序是通过组合许多单用途、小容量的网络服务来构建的。微服务架构让边界设计良好的服务的失效互不影响成为可能。但是，微服务和所有的分布式系统一样，也会存在各种各样的问题。此前，软件工程师谢哈尔·古拉蒂（Shekhar Gulati）在审查了多家数字化转型产品团队的架构后，总结了一些微服务失败的常见原因。InfoQ 中文站对其进行了翻译，以下为重点内容。
原因 1：管理层低估了开发微服务的复杂性
要开发微服务，开发人员需要一个高效的本地环境设置。
随着系统中的服务数量开始增加，在一台机器上运行应用程序的子集变得越来越困难。特别是当你使用消耗较多内存的语言（如 Java）构建应用程序时，更是如此。
下面是与本地开发设置相关的要点。
首先，一个好的开发机器是非常重要的。大多数组织想使用最新的、最先进的技术，但却不想替换掉糟糕的 Windows 开发机器。开发人员受限于他们的开发机器，工作效率自然会降低，
一旦你为开发人员配备了合适的开发机器，那么下一步就是确保所有服务都使用构建工具。你应该能够在一台新机器上构建整个应用程序，而不需要进行太多配置。接下来就是要让开发人员能够轻松地在他们的系统上运行应用程序的各个部分。在配置了所有端口和卷的情况下，你应该使用多个 docker-compose 文件来提供不同的服务。
如果组织对微服务开发的复杂性缺乏理解，那么团队的速度将会随着时间的推移而下降。
原因 2：未将库和工具更新到最新版本
团队没有确保依赖项是最新的版本，或者将像数据库这样的工具升级到最新版本。那么时间越长，技术债就会越多。需要记住的另一点是，要使所有服务的依赖项版本保持同步，定期将所有依赖项更新到最新版本。
原因 3：利用共享服务促进本地开发
由于本地开发状况不佳，大多数团队开始依赖于共享环境获得关键服务。大多数年轻的开发人员并没有意识到基于共享数据库的开发是“邪恶的”。比如：
一个开发人员可以删除其他开发人员编写的数据。
很难单独测试更改。你的集成测试将变得不可靠，从而进一步降低了开发速度。
只有共享数据库拥有系统工作所需的所有数据。随着时间的推移，团队成员失去了更改的可追溯性，因此没有人知道，他们该如何在他们的机器上复制相同的设置。唯一的方法是获取完整的数据库转储并使用它。
如果未连接到网络，就很难开展工作。
解决这些问题的最好方法是，让开发人员可以轻松地在他们的机器上运行数据库（作为 Docker 容器），并投资创建 SQL 脚本来设置模式和初始主数据。这些 SQL 脚本应该保存在版本控制中，并像维护任何其他代码一样进行维护。
原因 4：代码重用策略不明确
曾经某客户在他们所有基于 Java 的微服务复制了四个与特定问题相关的 Java 文件。因此，如果在该代码中发现 Bug 的话，就需要将其修复应用到所有地方。然而，在时间紧迫的情况下，人们总是默认采用简单且容易出错的做事方式。
正确的方法是，使用像 Bintray 或 Nexus 这样的工件管理器，并发布依赖项。然后，每个微服务都应该依赖于这个库。你需要构建工具，以便在发布新版本的库时，所有的微服务都应该进行更新和重新部署。
使用微服务并不意味着你不应该使用迄今为止对你有用的最佳实践。你需要对工具进行投资，使微服务的升级变得更容易。
以上就是微服务失败的其中四个原因，受篇幅所限，其余四个原因及正确解决方案将在下文分享。
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线笔记
复制
AI
- 深入了解
- 翻译
- 解释
- 总结
该免费文章来自《极客视点》，如需阅读全部文章，
请先领取课程
请先领取课程
免费领取
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
登录 后留言
全部留言(2)
- 最新
- 精选
幸运草分布式在提供快速开发和关键点服务可自由扩容的便捷的同时，但同时也更难驾驭，维护成本高（代码，硬件，软件升级），让开发失去了对项目的全局观，有全局观的架构师不关心服务细节，团队之间的矛盾升级。
小斧原因 1：管理层低估了开发微服务的复杂性 原因 2：未将库和工具更新到最新版本 原因 3：利用共享服务促进本地开发 原因 4：代码重用策略不明确
收起评论