本文将简单介绍微服务架构设计时需要注意的问题。如果实施得当，您将获得自主权和灵活性，但代价是通信延迟以及部署和托管成本。本文并非高级指南，只是希望它能帮助您在决定采用微服务架构时做出更好的判断。1.地图服务在我看来，地图服务是一个非常糟糕的主意。如果你走到这一步，可能是因为你需要在服务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、ApacheKafka。5.结语以上问题我希望你们中的大部分人都清楚，但肯定有一些人犯了这些错误，也许看完这篇文章你可以学到一些东西。无论如何，在不断变化的新微服务世界中犯错误是不可避免的。
