中小规模团队实践微服务可能遇到哪些挑战？
极客时间编辑部
讲述：初明明大小：4.31M时长：04:43
你好，欢迎收听极客视点。
随着微服务的火爆，很多中小团队都加入了实践微服务的大军，但几番试验之后，放弃微服务的企业不在少数。此前，Simple Thread 联合创始人贾斯汀·埃瑟里奇（Justin Etheredge）整理了很多公司放弃微服务的原因，并为实践微服务的中小企业列举出可能遇到的挑战。InfoQ 中文站对其进行了翻译，希望对你有所帮助。
1. 协调
每当需要进行较大的更改时，你就会发现自己需要更新许多服务，并且要协调这些服务的发布。当你向同事提起这件事时，他们总是说：“你弄错了，你的服务在逻辑上应该是分离的。”逻辑上分离，听起来很好，但是，你已经将系统拆分成许多小块，所以这些小块之间有很多依赖关系。有人曾经说过，如果你的服务之间有一堆依赖关系，那么你的拆分边界就有问题，但是，除了大幅减少微服务的数量外，你并不知道其他的拆分方法。
2. 数据一致性
你还会注意到，出现了一些数据一致性的新问题。看起来，应用程序中一些过去在单个操作中完成的操作现在被拆分到几个不同的服务中，其中一个服务有一些写入失败。同样，你的同事会告诉你，这样做是不对的，但是，将库存服务与订单服务拆分成单独的服务似乎是正确的，是符合微服务的精神的。你可能会构建工具来确保数据一致性，这会再一次让你觉得明显增加了一些工程复杂性和开销。
3. 性能挑战
性能问题也开始悄然出现，应用程序中的一些页面需要调用六个服务来呈现，加载时间很长。看起来，你需要为其中一些服务实现一个内部缓存层，以加快页面呈现速度。简单的缓存层不会特别麻烦，只是需要再添加一层。
4. 分布式跟踪
随着时间的推移，你还会开始注意到，团队记录的处理某些 Bug 的时间显著增加。当你与团队讨论这个问题时，他们会说，某些问题在系统中很难定位。即使他们找到了，也很难再现它们，因为在工程师的机器上让多个服务进入同样的状态会是一项巨大的挑战。你默默地记了下来，你需要从整体上做个规划，以便提供更好的系统级可跟踪性，这样，你就可以看到请求在整个系统中的流转过程。于是你又多了一个待办事项。
5. 重复
现在，设计和构建某些比较大的特性需要花费更长的时间了。它们需要多个不同的服务来实现不同的功能，并在不同的数据存储中协调更改。你会发现，自己在不同的服务中复制了某些业务操作的逻辑，尽管你已经尽了最大的努力来保证每个服务在逻辑上是独立的，但是，你没法完全做到这一点。这给表带来了各种不同的风险，因为现在需要在服务之间保持业务逻辑的一致性。
6. 报表挑战
如果将数据拆分到多个数据存储，一些查询就会变得非常复杂。因此，你聘请了一些顾问来帮助你构建一个专用的数据仓库并创建一个 ETL 过程，将其转换为让你的团队可以轻松生成报告的形式。这种设置提供了一些预期的优点，但是，现在每次进行重要的模式更改都必须同时维护 ETL 过程。又多了一件事要处理。
7. 稳定性
最后，稳定性开始出现问题。其中一个服务有点不稳定，在访问它时会导致系统的其他部分挂起。你看到的不是抛出的错误，而是请求静静地阻塞在那里，直到失去响应。你知道，你的团队没有花足够的时间来确保服务之间良好的容错能力，因此你意识到，可能需要使某些交互异步进行，这将进一步增加工程开销。
总之，通过采用微服务或微前端，你是在转移复杂性，而不是消除复杂性。在一些地方，这种转变是值得的，但是，如果你的系统不够大，你的团队成员不够多，而你面临的问题不是来自于协调大量的开发人员，那么将应用程序拆分成很多小块可能会弊大于利。
你需要清楚地了解你的系统所面临的挑战，看看整个团队不断增加的速度是否可以抵消构建分布式系统所带来的额外复杂性，然后再做出决策。所以需要你严格考察，谨慎行事。
以上就是今天的内容。你的团队正在或计划使用微服务吗？有没有遇到什么问题呢？
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线笔记
复制
AI
- 深入了解
- 翻译
- 解释
- 总结
该免费文章来自《极客视点》，如需阅读全部文章，
请先领取课程
请先领取课程
免费领取
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
登录 后留言
全部留言(1)
- 最新
- 精选
xiaochao321不要盲目拆分，拆分粒度的把控，不然会出现重复，一致性，稳定性，性能等的挑战
收起评论