关于代码恢复，安全性和数据库共享的微服务架构问题

Question

我有关于微服务架构的以下问题

1. 在不同的微服务之间如何重用常见的代码/实用程序库？这个共同代码也正在开发中的地方

2. 在我的微服务中，一些服务是针对客户的，一些可以是内部的（用于其他微服务）。使内部服务安全的最佳选择是什么？

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

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

Answer 1

免责声明：基于我使用各种基于微服务架构的经验，这些都是基于我的观点的答案。

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

2. 其中一种可能的方法是将其他微服务视为特定客户端，为其提供特定角色，允许执行某些操作。但是，您可以考虑部署仅在外部网络不可见的子网上应答的特定微服务。我仍然会在各方之间执行某种访问控制（虽然我从未使用它，但http://jwt.io/似乎正在接受）。身份验证机制与用于验证客户端的机制类似。

3. 我不会 - 特别是因为我在第1点所描述的内容。你将引入服务的高风险踩到彼此的脚趾，失去“独立”部分，这是面向微服务的关键建筑。每个服务都应拥有自己的存储，因为您应该能够在任何给定时间更改单个微服务的存储引擎，而不会改变其他服务的行为。

4. 我不完全确定你的意思。在与前端客户端进行交易时保持向后兼容性非常重要。您可以对您的微服务进行版本控制（例如/v1/messages，如果您使用的是REST类似的方法，那么请让您的客户使用特定版本的服务。通过使用不同的版本，您可以解耦前端和后端服务版本 - 再次 - 它们是独立的。

考虑起来似乎很多（实际上是这样），但从一开始就使用好的做法将导致以后避免很多问题。