Microservices 关于代码恢复、安全性和数据库共享的微服务体系结构问题

关于微服务体系结构，我有以下问题

如何在不同的微服务之间重用公共代码/实用程序库？该通用代码也正在开发中

在我的微服务中，有些服务是为客户提供的，有些服务可以是内部的（供其他微服务使用）。使内部服务安全的最佳选择是什么

如果两个微服务必须使用同一个数据库怎么办？假设它们执行完全不同的操作，但使用相同的数据库表

微服务主要是关于后端的，但GUI将是相同的。在这种情况下，每个微服务部署也需要网站更新。这是不是一个缺点？

---

免责声明：这些答案基于我的观点，基于我使用各种基于微服务的体系结构的经验

理想情况下，微服务应该是独立的，它们不应该共享二进制依赖项（特别是对于域概念）。事实上，特别是对于大型架构，这比乍一看更具挑战性。微服务背后的一个想法是，如果它们回复相同的消息，您可以在没有任何其他微服务注意的情况下彼此交换。当您开始引入二进制dedencies时，这很容易成为一场噩梦

一种可能的方法是将其他微服务视为特定的客户机，赋予它们特定的角色，允许执行某些操作。但是，您可以考虑部署只在外部网络不可见的子网上应答的特定微服务。我仍然会在各方之间执行某种访问控制（尽管我从未使用过它，似乎正在接受）。身份验证机制类似于用于对客户端进行身份验证的机制

我不会——特别是因为我在第1点上所描述的。您将引入一种高风险，即服务相互碰撞，失去“独立”部分，这是面向微服务的体系结构的关键。每个服务都应该拥有自己的存储，因为您应该能够在任何给定的时间更改单个微服务的存储引擎，而不会更改其他服务的行为

我不完全明白你在这里的意思。在处理前端客户端时，保持向后兼容性非常重要。您可以对微服务进行版本设置（例如，如果您在HTTP上使用类似REST的方法，则可以对微服务进行版本设置（例如，

/v1/messages

），然后让您的客户端使用特定版本的服务。通过使用不同的版本，您可以将前端和后端服务版本解耦，因此它们是独立的

这看起来需要考虑很多（事实上也是如此），但是从一开始就使用良好的实践可以避免以后出现很多问题