代码和服务布局之间的关注点分离(2010)

…。或者其他一些框架。请在评论中让我知道，我在这上面找不到任何东西，一定是搜索了错误的关键字。当发生这种情况时，我会在这里添加一个“编辑”来路由任何想要这样做的人。

最初，您可能会开始构建一个软件，然后它可能会成长为一个巨大的整体代码库。起初所有的东西都在一起是有好处的，但是如果东西粘在一起，你不能很容易地把它分开，那么以后就会令人沮丧。

另一个挑战是，SRE/OPS/DEVOP人员没有足够的细粒度控制来有效地拆分功能。

一些允许您轻松拆分(或组合)系统组件的设计。

此设计允许与开发人员分离关注点，并让运营人员选择布局。

我在前一个项目github.com/joekir/indelible中了解到，GRPC可以很容易地切换其“传输介质”，而不需要更改代码的功能。

这让我想到，如果您可以抽象出如何在代码中调用函数的传输机制，会怎么样。特别将其拆分为：

又名“目前并不存在的东西，需要它才能存在”

首先，您需要以某种方式在编码语言中修饰函数/模块/类/等，以指示应该隐式地为其生成协议。

..。Service<；TODO>；{RPC PrintSomething(PrintSomethingArgs)返回(google.protocol buf.Empty){}}消息PrintSomethingArgs{必需的字符串标题=1；可选的uint32 count=2；}...。

一旦有了这些，您就会希望在其中一个修饰函数之间进行的每个函数调用都有一些间隙代码来执行GRPC调用，而GRPC调用既可以这样做，也可以这样做。

Passthu-它简单地绕过所有GRPC，并允许正常的函数调用在进程内。

使用一些配置来确定它是应该通过IPC(进程间通信)对同一主机上的另一个进程/容器进行GRPC调用，还是应该通过TCP/UDP对网络上的进程进行GRPC调用。

然后，您需要一些运行时配置，操作团队可以利用这些配置来指示应该如何“当前”访问该函数。还需要添加一些Linter/编译器，以使语言知道您何时试图访问超出组件边界并期望具有某些共享状态的内容。

性能/可靠性/成本工程可以将重点放在系统的生产布局上，并具有更精细的控制以使其高效。

开发人员不再需要考虑GRPC以及调用是本地调用还是通过网络调用，如果它有一个装饰符，就会假设“它可能是”

我是一名安全工程师，所以我有时喜欢安全方面的东西。这里的装饰者还有另一个“约束”可能会很有趣。

在防御攻击方面，通常网络>；容器>；共享内存。因此，您可能有一些只希望在IPC或网络级别可用的安全关键代码。

就是这样，我还没有编写这个东西，因为1它看起来很难，2其他人可能已经做过了，3它可能是没用的，我只是还不知道为什么。在评论中让我知道！：)