码/公用事业库被不同的微服务之间的重用有关的微服务架构下面的问题如何共同微服务架构的问题？这个普通代码也在开发之中
在我的微服务中，有些服务是为客户端服务的，有些服务可以是内部的（用于其他微服务使用）。什么是使内部服务安全的最佳选择？
如果两个微服务必须使用相同的数据库会怎么样？说他们完全不同的操作，但使用相同的数据库表？
微服务主要是关于后端，但GUI将会是相同的。在这种情况下，每个微服务部署都需要网站更新。这是否被视为劣势？
免责声明：这些都是基于我的根据我的经验与各种基于微服务架构工作的观点答案。
理想的微服务应该是独立的，他们不应该共享二进制依赖（专为域概念）。实际上，特别是对于大型架构来说，这比起初看起来更具挑战性。微服务背后的一个想法是，如果他们回复相同的消息，您可以在没有任何其他微服务注意的情况下交换一个。当你开始引入二进制偏移时，这变成一场噩梦。
其中一种可能的方法是将其他微服务视为特定的客户端，为他们提供特定的角色以允许执行某些操作。但是，您可以考虑部署仅在外部网络不可见的子网上应答的特定微服务。我仍然会执行各方之间的某种访问控制（虽然我从来没有使用它，http://jwt.io/似乎正在接受）。身份验证机制与用于验证客户端的机制类似。
我不会 - 特别是因为我在第1点中描述的内容。您将引入服务跨越彼此脚趾的高风险，失去了“独立”部分，这是微服务导向架构的关键。每个服务都应该拥有自己的存储，因为您应该可以在任何给定时间更改单个微服务的存储引擎，而不会改变其他服务的行为。
我不完全确定你在这里的意思。在处理与前端客户端交易时保持向后兼容性非常重要。您可以对微服务进行版本升级（例如，如果您使用的是基于HTTP的REST类似方法，则为/v1/messages），然后让您的客户端使用特定版本的服务。通过使用不同的版本，您可以分离前端和后端服务版本，因此 - 再次 - 它们是独立的。
看起来好像需要考虑很多事情（实际上是这样），但是从一开始就采用良好的做法会导致以后避免很多问题。