目录
当从单体架构转换到微服务架构后，你会发现你的每个服务都有很多重叠的与业务无关的代码，比如状态存储，比如对接服务中心，再比如对接配置中心，再比如对接消息中间件，如果采用的直连sdk方式做服务治理，可能还会涉及到熔断、重试、限流等工作。还记得我们之前说过么，服务治理可以在api网关侧处理，还可以做serviceMesh通过边车来治理。
那有没有什么方式可以让我们从这些繁琐的sdk对接中解放出来，就像服务治理一样，只让我们的项目关注与业务呢？有的，是dapr。
1. dapr是什么
dapr是Distributed APplication Runtime（分布式应用运行时），由微软团队提供。它采用边车的方式让你可以快速构建你的微服务架构，它帮你解决了服务发现、状态存储、配置中心等一系列微服务架构需要解决的问题，有了它，你只需要与dapr边车进行简单的http或者grpc通信即可，再也不用考虑复杂的sdk接入了，并且每种能力都是可拔插的，简单配置便可替换背后存储的中间件，大大的简化了你应用开发的效率，你关注业务即可，dapr帮你解决微服务架构的问题。
近两年来dapr非常的火，据说已经超过当初k8s的火热程度了，国内阿里云也参与了此项目中，看看github的star数:
如此火爆的微服务解决方案，你怎能不了解。
2. 构建块
dapr更新特别快，一直在不断迭代，解决社区的问题和添加新的能力。目前笔者所用的版本是1.8。主要提供上述构建块功能：服务调用，状态管理，发布订阅，绑定，actors，可观测性，秘钥管理，配置管理，分布式锁。
《dapr入门系列》主要会对服务调用、状态存储、发布订阅、绑定、秘钥配置、可观测性进行一一介绍，每个构建块会有一个专门的文章进行介绍。下面先简单介绍下这几个构建块，让你有个初步的了解。
2.1 服务调用
还记得咱们之前提到过的微服务需要一个服务中心做服务注册和发现么，dapr的服务调用就是帮你做这个事情，你只需要向dapr边车发起请求，边车便会转发到对应的服务，你无需手动注册，也无需监控注册中心的服务地址变化，如下图所示：
以服务A调用B为例，流程如下：
1） 服务A向自己的dapr边车发起请求，告知边车，我要访问B服务
2）边车到name resolution组件解析B服务边车地址
3）A边车向B边车发起请求
4）B边车向serviceB发起请求
5）serviceB返回结果给B边车
6）B边车返回结果给A边车
7）A边车返回结果给serviceA
2.2 状态管理
分布式应用中状态存储最常用的情景就是共享session，dapr的状态管理组件可以屏蔽掉其实现逻辑，简单的通过配置组件和调用sidecar来实现。并且，你可以随意替换存储状态的组件，而不用修改一点代码。最常用的就是通过redis来进行状态存储。
2.3 发布订阅
用过消息队列的应该都明白发布订阅的作用吧，dapr可随意更换消息队列组件，只需要简单的配置和http/rpc请求，便可快速的对接消息组件，完全无需对接sdk，非常方便。
2.4 绑定
刚开始接触到绑定的概念时有点蒙，大概得意思是感觉可以不用集成组件的sdk，只需要通过与dapr交互即可，这大大提高了我们的开发速度。后续会有更详细的介绍。
2.5 可观测性
还记得我们之前提到过的链路追踪么？微服务系统链路追踪是非常重要的，它可以反应你服务间交互的运行情况，快速找出耗时链路。dapr可通过简单配置，便实现链路追踪，无需任何代码。
2.6 秘钥管理
你可以把秘钥（如数据库连接信息）放入云端，一个可保证数据的安全性，另一个可以保证信息变更时可快速变更，不用到每个服务去修改配置文件。
3. dapr-php-demo
《dapr入门系列》后续的文章里面的示例都在https://gitee.com/maque_486/dapr-php-demo中，读后续文章前，先把项目拉取到本地，把项目运行起来，关于项目介绍可查看项目的readme文件。
该项目使用docker-compose启动，需要读者有相关环境。
成功运行后，你可以看到以下服务:
515
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
