我正在使用微服务架构构建巨大的应用程序。该应用程序将包含多个后端微服务(部署在多个云实例上),其中一些我想使用 rest api 进行连接,以便在它们之间传递数据。
该应用程序还将向第三方公开公共 API,但上述端点应仅限于同一应用程序中的其他微服务,从而创建某种专用网络。
所以,我的问题是:
如何在同一应用程序中实现对其他微服务的受限 api 访问?
如果有比使用 http 传输层更好的连接微服务的方法,请提及。
如果可能,请保持答案服务器/语言不可知。
谢谢。
我正在使用微服务架构构建巨大的应用程序。该应用程序将包含多个后端微服务(部署在多个云实例上),其中一些我想使用 rest api 进行连接,以便在它们之间传递数据。
该应用程序还将向第三方公开公共 API,但上述端点应仅限于同一应用程序中的其他微服务,从而创建某种专用网络。
所以,我的问题是:
如何在同一应用程序中实现对其他微服务的受限 api 访问?
如果有比使用 http 传输层更好的连接微服务的方法,请提及。
如果可能,请保持答案服务器/语言不可知。
谢谢。
是的,很容易。微服务的每个客户端都有一个 API 密钥。微服务只接受来自具有有效 API 密钥的客户端的请求。
此外,很高兴知道 REST 只是一种允许在有界上下文之间进行通信的协议。
它不必通过 HTTP。要求是它有一个统一的接口(这就是 HTTP 与它的 PUT、POST、GET、DELETE... 方法一起使用的原因)并且它是无状态的(所有状态都通过 URI 传输)。
所以如果你所有的微服务都运行在同一个盒子上,你需要做的就是这样的:
class SomeClass implements RestfulMethods {
public function get(params){ // return something}
public function post(params){ // add something}
public function put(params){ // update something}
public function delete(params){ // delete something}
}
然后,微服务通过与其他服务的 RestfulMethod 实现交互来进行通信。
但是如果你的微服务在不同的机器上,最好使用 HTTP 作为传输机制。
一种方法是使用 HTTPS 进行内部 MS 通信。将访问(使用信任存储)锁定为仅对您的服务。您可以在服务之间共享证书以进行后端通信。最好是通配符证书。只要您的服务可以寻址到同一个域,它就应该可以工作。像 *.yourcompany.com。
一切就绪后,它应该可以正常工作。HTTPS 会话确实意味着一些开销,但这主要是在握手过程中。在会话中使用 keep-alive,加密通道不应该有太多开销。
当然,您也可以简单地将一些凭据添加到您的 http 标头中。那会不太安全。
RestAPI 不仅是实现它的方法,我的一些想法之一是关于使用Service Registry链接 Eureka (Netflix)、Zookeeper (Apache) 等。
这是一个例子:
...上述端点应仅限于同一应用程序中的其他微服务...
你说的广义上是授权。
授权是在您的应用程序中向真实用户授予或拒绝“权力”或“能力”。
因此,任何授权机制的工作都是验证任何入站 API 请求中隐含的“声明”——允许用户执行请求中编码的事情。
举个例子,假设我在你的 API 上出现了一个对 Widget 1234 的 PUT 请求:
PUT /widgetservice/widget/1234 HTTP/1.1
这可以解释为我(Bob Smith,一位知名用户)声称我可以更改您系统中 ID 为 1234 的小部件。
无论你做什么来验证这个声明,我希望你能看到这需要在应用程序级别完成,而不是在 API 级别。事实上,授权是应用程序级别的问题,而不是 API 级别的问题(与身份验证不同,身份验证在很大程度上是 API 级别的问题)。
为了演示,在上面的示例中,理论上可以允许我创建一个新的小部件,但不能更新现有的小部件:
POST /widgetservice/widget/1234 HTTP/1.1
甚至我只被允许更新小部件 1234 并且不应该允许更改其他小部件的请求
PUT /widgetservice/widget/5678 HTTP/1.1
如何在同一应用程序中实现对其他微服务的受限 api 访问?
因此,这变成了一个问题,即如何在应用程序中构建授权,以便验证来自已知用户的单个请求(在您的情况下,您生态系统中的其他服务只是另一种已知用户)。
好吧,很抱歉,但我将在这里进行说明,您可以使用基于声明的授权服务,该服务根据用户身份或角色成员身份存储有效声明。
这在很大程度上取决于您如何处理身份验证,以及您是否在该过程中支持角色。您可以存储针对单个用户的索赔,但随着用户数量的增加,这变得很困难。OAuth尽管实施起来相当繁重,但却是这方面的领先平台。
我正在使用微服务架构构建巨大的应用程序
我在这里唯一要说的就是先阅读这个。
最简单的方法是只允许从运行微服务的 IP 地址进行访问。
我知道这个问题我已经很晚了 :)) 但是对于遇到这个线程的任何人来说,Kafka是类似于这个问题的操作的一个很好的选择。
基于Kafka自己的介绍
Kafka 通常用于两大类应用程序:
- 构建实时流数据管道,在系统或应用程序之间可靠地获取数据
- 构建实时流应用程序以转换或响应数据流
旁注:Kafka 由 LinkedIn 创建,并在许多大公司中使用,因此它经过了实战考验。