微服务架构陷阱：过度设计和设计不足
极客时间编辑部
讲述：初明明大小：3.41M时长：03:43
近日，技术博客主 Code Lime 发布文章，简要地介绍了在设计微服务架构时需要注意的问题。他表示，如果实施得当，你的微服务架构就会获得自治能力和灵活性，但同时也会带来通信延迟和部署及托管成本，希望这篇文章能帮助技术同学在决定是否采用微服务架构时做出更好的判断。以下为原文内容。
映射服务
在我看来，映射服务是一种很糟糕的想法。
如果你走到了这一步，很可能是因为你需要在服务 A 和服务 B 之间映射 DTO，因为服务 A 和服务 B 需要不同的 DTO，但它们之间又相互依赖。出于对微服务的“热爱”，你尝试着解耦这两个服务，于是你创建了服务 C。服务 C 接收 JSON 数据，并把稍微处理后的数据返回，其他什么事也不做。
现在，你的三个服务都耦合在一起了。DTO 到 DTO 的映射应该发生在进程内部，否则的话，可能会有人创建出新的服务来映射服务 A 和服务 C 之间的 DTO。除非服务 C 不会往实体中添加新数据，否则它的存在就不是必要的。一个服务应该只返回它所拥有的数据。
同样，你会为了给一组数字排序而专门创建一个服务吗？
静态内容的映射服务
并不是所有东西都需要被包装成微服务，网站的静态资源，比如脚本、样式表或图像，要么把它们放在主服务器上，要么放在 CDN 上。
对于后端服务，如果需要在初始化的时候读取一些简单的字符串，而这些字符串很少发生变化，可能几个月或者几天才会修改一次，那么可以考虑使用冷存储，比如亚马逊的 S3 或者微软的 BlogStorage。需要访问控制？可以考虑基于 IP 或域名的访问限制。所以，在考虑是否需要创建新的微服务时，要十分谨慎，因为它可能会给你带来巨大的维护和托管成本。
将应用程序的配置托管在远程服务上
线程池该配置多少个线程？重试策略该怎么配？本地内存缓存的有效时间设置多久合适？需要通过一个远程服务来配置这些东西吗？在很多情况下，把这些东西放在配置文件或者环境变量里是完全可以的，所以可以先考虑这种方式。如果不行，可以尝试一些已有的配置工具，比如 Consul，尽量避免自己开发浪费时间和精力。
多个服务共享一个数据库
如果架构过于简单，很快也会遇到问题。如果多个服务共享一个数据库，数据库的连接、存储空间和计算能力很快就会不够用。接下来就会出现一些不太好的局面——一些服务使用的表被删掉了。或者，有两个客户端使用了同一张表，其中一个客户单要求对表结构做出修改，这个时候就需要做一些适配才能不影响另一个客户端。在我看来，现在的系统变成了一个分布式单体。
而这样做有悖于微服务架构的原则，因为微服务应该是独立且自包含的。它们应该拥有自己的数据，并可以完全自由决定该怎么持久化数据。它们存在的目的是为了解耦，为了获得这种灵活性，你需要付出一定的代价，但追求灵活性应该成为你的目标。
微服务之间应该通过公开暴露的 API 进行交互。基于 HTTP 的通信可以选择 REST、GraphQL、gRPC，或者也可以使用消息队列，比如 RabbitMQ、Apache Kafka。
以上就是今天的内容，希望对你有所帮助。
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线笔记
复制
AI
- 深入了解
- 翻译
- 解释
- 总结
该免费文章来自《极客视点》，如需阅读全部文章，
请先领取课程
请先领取课程
免费领取
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
登录 后留言
精选留言
由作者筛选后的优质留言将会公开显示，欢迎踊跃留言。
收起评论