微服务架构设计分布式运行

分布式运行时
在编程模型中的分布式运行时，也就是我们希望微服务能够有更好的多语言环境支持、环境可移植性并能做到极速启动。
单体应用时代，我们的业务代码跟中间件代码耦合在一起，而且是一份部署的实例；当到了微服务时代，通过像 Service Mesh 服务网格进行流量管理之后，可以看到我们的业务代码和流量管理代码实际上是可分离的，只有部分中间件的代码仍然和部分业务代码耦合在一起形成一个二进制。
为了能够做到充分的多语言能力支持、环境的可移植性，我们希望能够把剩余的中间件代码也从业务中解耦出来，这项技术叫做运行时解耦。它的根本理念是通过向业务代码提供一个标准的可扩展 API，并且是一个多语言可支持、轻量级的 API，通过调用 API 来实现中间件的功能，我们把中间件的能力像流量管理一样下沉到一个 Sidecar 中，用一种语言进行统一实现，然后设计一个可拔插的模式，让大家能够拔插更多中间件的能力。
这项技术比较领先的一个实践是微软去年推出的一个分布式运行时，叫做 Dapr。
Dapr 向业务的代码暴露了两个 API，一个是 HTTP 的 API，另外一个是 grpc 的 API。这两个 API 都非常轻量级，并能够跨多种语言，Dapr 本身作为分布式运行时，可以对接多种中间件系统，向上通过标准的 API 屏蔽不同系统之间的差异性，提供一定的编程界面界面统一。代码实现上把中间件的代码从应用级别抽离到 Sidecar 中，如上图所示，我们在业务上面只需要写业务的代码，其他代码几乎都被基于 Dapr 的平台所接管。
Dapr 本身分为两部分：第一部分是 Dapr 向 Application 暴露的 API，另一部分是 Dapr 的框架层。
通过 Dapr 的框架层，我们可以接入各种不同的 Dapr 相关实现：Resource bandings 如 Kafka/SQS、管理数据的如 Redis/cassandra、或者我们去做 Publish & subscribe 如 RabbitMQ、甚至 Distributed Tracing 如 Prometheus/Open tracing 等等，都可以接入到 Dapr 这套框架里，然后通过统一的标准 HTTP、gRPC API 提供给业务代码、应用代码去使用，这样就做到了业务代码与中间件、流量管理能力的更彻底的解耦，应用的开发人员也能够更专注、更自由地去关注业务代码研发。