微服务架构圈套 过渡设计和设计无余

在这篇文章里，我将简明地引见在设计微服务架构时须要留意的疑问。假设实施切当，就会取得自治才干和灵敏性，但同时也会带来通讯提前和部署及托管老本。这篇文章并不是一个初级指南，我只是宿愿能够在你们选择驳回微服务架构时帮你们做出更好的判别。

映射服务

在我看来，映射服务是一种很蹩脚的想法。

假设你走到了这一步，很或许是由于你须要在服务 A 和服务 B 之间映射 DTO，由于服务 A 和服务 B 须要不同的 DTO，但它们之间又相互依赖。出于对微服务的“热爱”，你尝试着解耦这两个服务，于是你创立了服务 C。服务 C 接纳 JSON 数据，并把稍微处置后的数据前往，其余什么事也不做。

如今，你的三个服务都耦合在一同了。DTO 到 DTO 的映射应该出当初进程外部，否则的话，或许会有人创立出新的服务来映射服务 A 和服务 C 之间的 DTO。除非服务 C 不会往实体中减少新数据，否则它的存在就不是必要的。一个服务应该只前往它所领有的数据。

雷同，你会为了给一组数字排序而专门创立一个服务吗？

2. 静态内容的映射服务

并不是一切物品都须要被包装成微服务，网站的静态资源，比如脚本、样式表或图像，要么把它们放在主主机上，要么放在 CDN 上。

关于后端服务，假设须要在初始化的时刻读取一些便捷的字符串，而这些字符串很少出现变动，或许几个月或许几天赋会修正一次性，那么可以思索经常使用冷存储，比如亚马逊的 S3 或许微软的 BlogStorage。须要访问控制？可以思索基于 IP 或域名的访问限度。所以，在思索能否须要创立新的微服务时，要十分审慎，由于它或许会给你带来渺小的保养和托管老本。

另外请留意，耐久存储必需是散布式可伸缩的。出于便捷起见，数据应该驳回键值对的方式，否则就会遇到与“多个服务共享一个数据库”一样的疑问。

3. 将运行程序的性能托管在远程服务上

线程池该性能多少个线程？重试战略该怎样配？本地内存缓存的有效期间设置多久适合？须要经过一个远程服务来性能这些物品吗？在很多状况下，把这些物品放在性能文件或许环境变量里是齐全可以的，所以可以先思索这种方式。假设不行，可以尝试一些已有的性能工具，比如 Consul，尽量防止自己开发糜费期间和精神。

4. 多个服务共享一个数据库

假设架构过于便捷，很快也会遇到疑问。假设多个服务共享一个数据库，数据库的衔接、存储空间和计算才干很快就会不够用。接上去就会出现一些不太好的局面——一些服务经常使用的表被删掉了。或许，有两个客户端经常使用了同一张表，其中一个客户单要求对表结构做出修正，这个时刻就须要做一些适配才干不影响另一个客户端。在我看来，如今的系统变成了一个散布式单体。

这样做有悖微服务架构的准则，由于微服务应该是独立且自蕴含的。它们应该领有自己的数据，并可以齐全自在选择该怎样耐久化数据。它们存在的目的是为了解耦，为了取得这种灵敏性，须要付出必定的代价，但谋求灵敏性应该成为你的指标。

微服务之间应该经过地下泄露的 API 启动交互。基于 HTTP 的通讯可以选用 REST、GraphQL、gRPC，或许也可以经常使用信息队列，比如 RabbitMQ、Apache Kafka。

5. 论断

宿愿你们大局部人都很清楚上述的这些疑问，不过必需会有一些人犯下这些失误，兴许看了本文后你能学到一些。不论怎样，在微服务这个离奇和多变的环球里犯点失误是在劫难逃的。