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

问题描述

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

I have the following questions about micro service architecture

1. 如何在不同的微服务之间重用常见的代码/实用程序库?还在开发通用代码的地方

1. How common code/utility-libs are being reused between different micro services? Where this common code is also being developed

在我的微服务中，一些服务是为客户提供的，而某些服务可以是内部的(供其他微服务使用).确保内部服务安全的最佳选择是什么?

In my micro-service some services are for clients and some can be internal ( for other micro services to use). What is the best option to make internal services secure?

如果两个微服务必须使用同一数据库怎么办?说他们执行完全不同的操作，但是使用相同的数据库表吗?

What if two micro-services has to use the same database? Say they do totally different operations but using the same database table?

微服务主要是关于后端的，但GUI将会是相同的.在这种情况下，每个微服务部署也需要网站更新.这是不利条件吗?

Micro services are mostly about the back end but the GUI is going to be the same. In that case each micro service deployment requires website update as well. Is that consider as a disadvantage?

推荐答案

免责声明:这些是基于我的观点，基于我在各种基于微服务的架构上的经验.

DISCLAIMER: These are answers based on my point of view based on my experience working with various microservice based architecture.

理想情况下，

1. 微服务应该是独立的，并且不应该共享二进制依赖性(特别是对于域概念).实际上，特别是对于大型体系结构，这比乍看起来似乎更具挑战性.微服务背后的想法之一是，您可以在不通知其他任何微服务的情况下将它们彼此交换，只要它们回复相同的消息即可.当您开始引入二进制依赖时，这很容易成为噩梦.

1. Ideally microservices should be independent and they shouldn't share binary dependencies (specially for domain concepts). In reality, specially for big architectures, that is more challenging than it seems at first sight. One of the idea behind microservices is that you could swap one for another without any other microservice noticing, provided they reply to the same messages. This becomes easily a nightmare when you start introducing binary depdencies.

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

One of the possible approaches would be to treat other microservice as a particular client, giving them a specific role that allows for certain operations to be executed. However, you can consider deploy a specific microservice that only answers on a subnet non visible by the outside network. I would still perform some kind of access control between parties (although I never used it, http://jwt.io/ seems to be picking up). The mechanism for authentication would be similar to the one used to authenticate your clients.

我不会-特别是因为我在第1点所描述的.您将面临服务互相踩脚的高风险，而失去了独立"部分，这对于面向微服务的关键建筑学.每个服务都应该拥有自己的存储，因为您应该可以在任何给定时间更改单个微服务的存储引擎，而无需更改其他服务的行为.

I wouldn't - specially because of what I described on point 1. You'll be introducing a high risk of services stepping on each other toes, losing the "independent" part which is key for a microservices oriented architecture. Every service should own its own storage, because you should be able to be change storage engine for a single microservice at any given time without changing behaviour of the other services.

我不确定您在这里的意思.与前端客户端打交道时，保持向后兼容性非常重要.您可以对微服务进行版本控制(例如，如果使用REST之类的HTTP方式，则使用/v1/messages)，然后让您的客户端使用该服务的特定版本.通过使用不同的版本，您可以使前端和后端服务版本脱钩，因此-再次-它们是独立的.

I'm not entirely sure what you mean here. It's very important to maintain backwards compatibility when dealing i.e. with frontend client. You can version your microservices (e.g. /v1/messages if you're using a REST like approach over HTTP), then have your client use a specific version of the service. By using different version, you can decouple frontend and backend service releases so - again - they're independent.

要思考的事情(实际上是很多事情)，但是从一开始就使用良好的做法将可以避免以后出现很多问题.

It looks like a lot to think about (and it actually is), but using good practices from the start will lead to avoid a lot of problems later.

这篇关于关于代码恢复，安全性和数据库共享的微服务架构问题的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！