之前的章节我们介绍了如何通过dapr发起一个服务调用，相信看过前几章的小伙伴已经对dapr有一个基本的了解了，今天我们来聊一聊dapr的另外一个功能——订阅发布
目录：
一、通过Dapr实现一个简单的基于.net的微服务电商系统
二、通过Dapr实现一个简单的基于.net的微服务电商系统(二)——通讯框架讲解
三、通过Dapr实现一个简单的基于.net的微服务电商系统(三)——一步一步教你如何撸Dapr
四、通过Dapr实现一个简单的基于.net的微服务电商系统(四)——一步一步教你如何撸Dapr之订阅发布
附录：(如果你觉得对你有用，请给个star)
一、电商Demo地址
二、通讯框架地址
惯例我们还是再老生常谈一下什么是订阅发布，订阅发布是根据设计模式之观察者模式发展出来的一种软件系统设计思想，它的核心是指“多个对象间存在一对多的依赖关系，当一个对象的状态发生改变时，所有依赖于它的对象都得到通知并被自动更新”。假设一个系统有ABC三个模块其中BC依赖于A，当A进行改变后需要A主动调用BC进行相应改变，而观察者模式则将A的控制权剥离，A改变之后只是发送一个事件给消息总线“我改变了”，BC通过预先订阅该主题而获取到A的状态变化，再进行自身的状态变更。
强耦合调用模式
通过消息中间件订阅发布模式
聪明的同学应该发现了，通过订阅发布其实我们是将以往强耦合的ABC通过巧妙的控制权转移的方式进行了解耦，由之前的BC依赖于A改为了BC依赖于消息组件，通过消息组件接受到A的消息后进行分发，这样设计系统的目的当然有好有坏，好处是这会大大提高A的吞吐量，假设以往操作ABC总耗时300ms平均单个操作耗时100ms，通过解耦后A耗时100ms后就可以马上返回线程。那坏处是什么呢，由于对BC进行了解耦往往状态的一致性就得不到保障了。当ABC处于同一个粗粒度的原子操作里（比如数据库事务操作、比如lock锁），我们很容易控制ABC的强一致性，ABC有一个操作失败可以很轻松的进行回滚而不用影响我们持久化设备的数据一致。另外由于需要依赖第三方中间件，整个系统的健壮性是会有一定影响的。另外还需要考虑订阅方消费失败、异常后如何处理。关于这部分内容这里我们就不展开了，如果大家确实感兴趣，推荐大家看看国内开源作者@杨晓东写的.netcore分布式一致性解决方案CAP，地址：https://github.com/dotnetcore/cap
OK，老生常谈的部分唠完，咱今天就来唠唠在Dapr中如何实现订阅发布的。通过上面的部分大家应该知道如果要实现一个进程间的订阅发布系统，我们需要准备很多东西，其中一个是事件总线，事件总线的作用是让事件发布者可以通过该模块进行事件发布。第二个需要选型一个消息组件，第三需要订阅器对订阅特定类型组件的技术支持。由于每一种组件其协议和接口实现方式都不同，在传统的订阅发布设计中我们往往需要对某种特定类型的消息组件在基础设施层进行相应的SDK集成，通过为业务层提供事件总线接口和订阅接口来进行技术解耦。就算做到了业务系统中不耦合技术实现，往往我们也很难替换消息组件。而Dapr在这方面为开发者集成了相当一部分的主流订阅发布组件(通过该支持列表可预览支持)。同时在业务层面是完全基于http+谓词的形式来实现订阅发布的。这就大大降低了引入SDK产生的成本。
订阅发布的API如下：
POST http://localhost:<daprPort>/v1.0/publish/<pubsubname>/<topic>[?<metadata>]