关于代码恢复、安全和数据库共享的微服务架构问题
microservice architecture questions about code resue, security and database sharing
我对微服务架构有如下疑问
code/utility-libs 在不同的微服务之间重用的频率如何？此通用代码也在开发中
在我的微服务中，有些服务是面向客户端的，有些可以是内部的（供其他微服务使用）。确保内部服务安全的最佳选择是什么？
如果两个微服务必须使用同一个数据库怎么办？假设他们执行完全不同的操作但使用相同的数据库 table?
微服务主要是关于后端的，但 GUI 是一样的。在那种情况下，每个微服务部署也需要网站更新。这算是劣势吗？
免责声明：这些是基于我的观点的答案，基于我使用各种基于微服务的架构的经验。
理想情况下，微服务应该是独立的，它们不应该共享二进制依赖项（特别是对于领域概念）。实际上，特别是对于大型架构，这比乍看起来更具挑战性。微服务背后的一个想法是，如果它们回复相同的消息，您可以在没有任何其他微服务注意到的情况下将一个交换为另一个。当您开始引入二进制依赖项时，这很容易成为一场噩梦。
一种可能的方法是将其他微服务视为特定的客户端，赋予它们特定的角色，允许执行某些操作。但是，您可以考虑部署一个特定的微服务，该微服务仅在外部网络不可见的子网上应答。我仍然会在各方之间执行某种访问控制（尽管我从未使用过它，http://jwt.io/ 似乎正在接受）。身份验证机制类似于用于对您的客户端进行身份验证的机制。
我不会 - 特别是因为我在第 1 点中描述的内容。您将引入服务相互踩踏的高风险，失去 "independent" 部分是面向微服务架构的关键。每个服务都应该拥有自己的存储，因为您应该能够在任何给定时间更改单个微服务的存储引擎，而无需更改其他服务的行为。
我不完全确定你在这里的意思。在处理前端客户端时保持向后兼容性非常重要。您可以对微服务进行版本控制（例如 /v1/messages，如果您使用 REST 之类的 HTTP 方法），然后让您的客户端使用该服务的特定版本。通过使用不同的版本，您可以分离前端和后端服务版本，因此 - 同样 - 它们是独立的。
看起来需要考虑很多（实际上也是），但是从一开始就采用良好的做法可以避免以后出现很多问题。
我对微服务架构有如下疑问
code/utility-libs 在不同的微服务之间重用的频率如何？此通用代码也在开发中
在我的微服务中，有些服务是面向客户端的，有些可以是内部的（供其他微服务使用）。确保内部服务安全的最佳选择是什么？
如果两个微服务必须使用同一个数据库怎么办？假设他们执行完全不同的操作但使用相同的数据库 table?
微服务主要是关于后端的，但 GUI 是一样的。在那种情况下，每个微服务部署也需要网站更新。这算是劣势吗？
免责声明：这些是基于我的观点的答案，基于我使用各种基于微服务的架构的经验。
理想情况下，微服务应该是独立的，它们不应该共享二进制依赖项（特别是对于领域概念）。实际上，特别是对于大型架构，这比乍看起来更具挑战性。微服务背后的一个想法是，如果它们回复相同的消息，您可以在没有任何其他微服务注意到的情况下将一个交换为另一个。当您开始引入二进制依赖项时，这很容易成为一场噩梦。
一种可能的方法是将其他微服务视为特定的客户端，赋予它们特定的角色，允许执行某些操作。但是，您可以考虑部署一个特定的微服务，该微服务仅在外部网络不可见的子网上应答。我仍然会在各方之间执行某种访问控制（尽管我从未使用过它，http://jwt.io/ 似乎正在接受）。身份验证机制类似于用于对您的客户端进行身份验证的机制。
我不会 - 特别是因为我在第 1 点中描述的内容。您将引入服务相互踩踏的高风险，失去 "independent" 部分是面向微服务架构的关键。每个服务都应该拥有自己的存储，因为您应该能够在任何给定时间更改单个微服务的存储引擎，而无需更改其他服务的行为。
我不完全确定你在这里的意思。在处理前端客户端时保持向后兼容性非常重要。您可以对微服务进行版本控制（例如
/v1/messages，如果您使用REST之类的 HTTP 方法），然后让您的客户端使用该服务的特定版本。通过使用不同的版本，您可以分离前端和后端服务版本，因此 - 同样 - 它们是独立的。
看起来需要考虑很多（实际上也是），但是从一开始就采用良好的做法可以避免以后出现很多问题。