@5app/buslane 中文文档教程
Buslane
Intro
Buslane 是一个跨服务和透明的 object.method 代理，使用 rpc-lite json/http1 传输。
当我们决定在 5app 迁移到 docker 时，就需要这个库。 我想要一种简单的方法来删除服务之间的直接代码依赖性，而无需手动添加额外的端点。
使用 buslane 及其类似对象代理的 RPC，您可以在远程对象上调用方法，就好像它们在同一上下文中一样。 因此也不需要创建特定的服务端点。 只需编写配置，buslane 就会将对象相互公开。
这仍然是非常实验性的，所以谨慎使用，我肯定是。
Config & Usage
使用以下方法安装 buslane 包：
npm install --save @5app/buslane
现在，您需要创建一个 Buslane 实例，您可以使用它来使 service1 和 service2 通信：
const Buslane = require('@5app/buslane');
const thisServiceName = 'service1';
const config = {
name: thisServiceName,
shared_api_key: 'my shared secret key',
map: [
{name: 'service2', port: 11211, ingresses: ['boat']},
{name: thisServiceName, port: 11311, ingresses: []},
],
};
const buslane = new Buslane(config);
const rpcResult = await buslane.service2.boat.sail('ocean');
Test
使用 docker构建和运行：
docker build -t buslane . && docker run buslane
Comparison with Buslane 2
Buslane 3 使用HTTP1 而 Buslane 2 使用 HTTP2。 放弃 HTTP2 以支持 HTTP1 的决定是为了解决 2 个问题：
- Recover connections after the service recovers: this can also be achieved by re-attempting connections and handling extra HTTP2 headers like
GOAWAY(in addition to the currentERR_HTTP2_INVALID_SESSION). - Load balancing requests between multiple instances of the same service: HTTP2 creates a session which binds 2 services (instances) together using a TCP connection. As a session-less protocol, HTTP1 does not have this issue, but on the other hand, there will be a handshake every time a request is made (with extra overhead compared to HTTP2).
Buslane
Intro
Buslane is a cross-service and transparent object.method proxy, using an rpc-lite json/http1 transport.
The need for this lib came about when we decided to move to docker at 5app. I wanted a simple way to remove our direct code dependencies between services without having to add extra endpoints manually.
With buslane and its RPC like object proxying, you can call methods on remote objects as if they were in the same context. So there is no need to create specific service endpoints either. Just write the configuration and buslane will expose the objects to each other.
This is all still very experimental, so use with caution, I sure am.
Config & Usage
Install the buslane package using:
npm install --save @5app/buslane
Now, you will need to create a Buslane instance which you can use to make service1 and service2 communicate:
const Buslane = require('@5app/buslane');
const thisServiceName = 'service1';
const config = {
name: thisServiceName,
shared_api_key: 'my shared secret key',
map: [
{name: 'service2', port: 11211, ingresses: ['boat']},
{name: thisServiceName, port: 11311, ingresses: []},
],
};
const buslane = new Buslane(config);
const rpcResult = await buslane.service2.boat.sail('ocean');
Test
build and run with docker:
docker build -t buslane . && docker run buslane
Comparison with Buslane 2
Buslane 3 uses HTTP1 while Buslane 2 uses HTTP2. The decision on dropping HTTP2 in favour of HTTP1 was made in order to resolve 2 issues:
- Recover connections after the service recovers: this can also be achieved by re-attempting connections and handling extra HTTP2 headers like
GOAWAY(in addition to the currentERR_HTTP2_INVALID_SESSION). - Load balancing requests between multiple instances of the same service: HTTP2 creates a session which binds 2 services (instances) together using a TCP connection. As a session-less protocol, HTTP1 does not have this issue, but on the other hand, there will be a handshake every time a request is made (with extra overhead compared to HTTP2).
