Dapr挎斗模式2：挎斗是如何迫使开发人员专注于业务的
Dapr简化了微服务的开发和部署，使开发人员专注于业务，全程处于业务员的高度，大大提升了开发效率，而运维人员负责挎斗维护，也使项目组不再担心项目的平稳落地。想象一下开发人员每一天都是乘坐飞机在 20,000 英尺的高空中工作的， 当他看向窗外，从广阔的角度看到下面的风景，会发现——世界两万英尺范围内，均分布有运维体系架构。
上篇的结尾暴露了Dapr的“野心”——将开发人员束之高阁，迫使其专注于业务。这符合项目组内的产品、测试、运维等等所有人的期望，开发人员理应时刻保持在业务员的高度行事，保证项目组成员之间得以高效的沟通与反馈。
1、开发人员不专注于业务的后果到底有多可怕
开发人员不关注业务的后果，就如同飞机故障从两万英尺的高度一步步的跌落到谷底。在初期，最明显的表现就是项目组成员之间的沟通成本增大了。开发人员把过多的精力花费在行业技术和运维工具的简单使用当中，收益甚微的同时，也导致自身业务水平急剧下降。信息在沟通、传递的过程中，可能会“失真”，别人讲的你不一定能100%理解，你只是以为你还能理解，可长期脱离业务的你还是当初那个坐在飞机上端着咖啡俯瞰大地的你吗？认清现实吧，长久以来你每天都在退步，跟以前的自己早就渐行渐远了。
运维工具的安装与使用是运维人员的工作，妄想产品能和“运维”一起愉快的探讨论业务是行不通的。开发人员是服务于客户的，IT行业技术是服务于业务的，没有业务的话IT行业技术也就没有生存的价值了。而鉴定一个功能是不是好功能，唯一的标准是看它能否支撑业务、改善业务、推动业务。这个标准能否统一，才是项目组成员之间能否轻松沟通的关键。
注意，这里称其为【IT行业技术】，同样的在军队文职考试中称软件岗为【专业技术】岗，这表明你不能直接用【技术】这个词，而是必须给它明确的限定一个范围。因为【技术】这个词是娱乐会所里的专用语，这是众所周知的事情。我们称之为【IT行业技术】，是为了避免误会，也是最基本的礼貌。无论是作什么职业，最起码的要求就是绝不能脱离社会，要融入大众，紧跟时事，这是保证沟通能力不掉链子的基本素养。
2、开发人员为什么会跑去关注运维工具？
开发架构缺少分布式框架和操作系统的支持，导致分布式面临的状态管理、服务调用、企业总线、可观察性等难点均需要开发人员去解决。当开发人员被迫的将主要精力集中在一大堆的非业务的问题上时，那表示整个项目组面临着被拖入泥潭的风险，必将严重拖慢开发节奏。
上面提到的非业务的问题指的就是运维工具，以及运维工具附加的IT行业技术。
这里以状态管理为例，当项目里的某个需求涉及到了一个“后写入优先”策略的缓存功能，虽然这在整个产品设计中只是微不足道的一个点罢了，可能只是稍稍提了那么一句，但对开发人员来说很可能是一个巨大的工作量。
他需要跟项目组确认测试环境和生产环境中可选择的状态管理工具：
- MongoDB
- PostgreSQL
- Redis
- Hashicorp Consul
- Hazelcast
- Memcached
- Zookeeper
。。。。。。
假设敲定的可选工具为Memcached和Redis,那么接下来他需要和运维人员讨论以作出最终选择。现在的问题是，有些开发人员没有在开发环境中使用Redis的经验，而有些运维人员也不知道Memcached为何物，所以无论选择了Memcached还是Redis都需要进一步投入工作量。选择Memcached，需要开发人员跟运维人员进一步沟通，以确认运维人员有能力将项目落地。选择Redis，则需要运维人员指导开发人员完成在开发环境安装Redis和客户端工具，开发人员还要去了解工具相关的代码库等准备工作，这里就是最明显的运维工具所附加的IT行业技术。
这个耗时的过程走下来，甚至是没有一丝一毫是和业务有关系的，开发人员的时间全被浪费在非业务的沟通中了。即便是我们的开发人员经验老到，缓存的相关原理和应用场景倒背如流，但是并没有用武之地呀。好钢用在刀刃上，好活儿用在业务上，运维工具所附加的IT行业技术不过是个库罢了，却浪费了开发人员太多的时间。
3、Dapr是如何迫使开发人员专注于业务的
这里以状态管理为例，当项目里的某个需求涉及到了一个“后写入优先”策略的缓存功能，这在整个产品设计中只是微不足道的一个点罢了，在Dapr中这对开发人员来说也是！
产品：相关需求啦啦啦，注意这里需要一个缓存的功能
开发人员：讨论需求，精研业务
初始化本地自承载开发时，Dapr 的状态管理组件将 Redis 注册为默认状态存储，默认名称statestore，相关配置文件内容如下：
apiVersion: dapr.io/v1alpha1
kind: Component
metadata:
name: statestore
spec:
type: state.redis
version: v1
metadata:
- name: redisHost
value: localhost:6379
- name: redisPassword
value: ""
- name: actorStateStore
value: "true"通过组件的方式,运维人员可以松耦合低成本的替换具体的中间件,例如将 redis 存储换成 memcached,只需要在声明式配置文件中将类型变更为 type:state.memcached,其他的无需任何改造。
开发人员无需关心状态存储到底是何种工具，不需要对配置文件作出变更，因为不管是何种工具，相关开发语言的挎斗API都是一致的，开发人员的工作就是补全当中的业务逻辑，如下：
var model = await daprClient.GetStateAndETagAsync("statestore", key);
// ... 业务逻辑
var result = await daprClient.TrySaveStateAsync("statestore", key, T); 实际的应用当中，可以根据业务的粒度进一步封装，比如封装到缓存过滤器中，通过过滤器统一管理控制器和方法的缓存，或者在管道中作全局缓存处理，这就更需要充分理解业务，判定是否有动全身的必要。
而运维人员在测试环境中部署时，需要和项目组确认生产环境可选择的状态管理工具：
- MongoDB
- PostgreSQL
- Redis
- Hashicorp Consul
- Hazelcast
- Memcached
- Zookeeper
。。。。。。
假设敲定的可选工具为Memcached和Redis,那么接下来他需要根据自身因素作出选择，通过配置Dapr的状态管理组件和机密管理组件完成在测试环境中的部署。这里涉及到的本就是运维工具，把问题抛给运维人员是最佳解决办法，即便是后期的生产环境瓶颈问题，相关的集群主从配置也是运维人员的工作。
开发：单体架构→模块化→分布式(微服务)
运维：单机→集群
当年的DotNetNuke应用框架横空出世，简直是将模块化玩出花来了，也是微软第一次向开源说”Yes”的里程碑。它在告诉人们两个道理，那就是模块化做得好，分布式随便搞;单体架构(业务)做得好，集群随便搞。一旦项目落地时没有埋藏的业务问题，那么对模块化、可插拔的灵活的单体架构而言，搞集群眼见的不就是加一台负载均衡服务器的事儿吗。至于运维人员到底是用什么工具用什么方式落地的，随他去吧。
4、被运维架构束之高阁的开发人员应该如何自居？
行业技术的发展，再加上疫情等因素的影响，可以预见未来的几年都是运维人员的天下，在很长的一段时间里，IT行业主要的任务都将围绕运维工具的使用，包括状态管理、服务调用、企业总线、可观察性等均是运维人员的工作。
在此敬告各位开发人员，赶紧回归业务吧，再不专注业务的话，就真的要没有立锥之地了。大家要蛰伏起来，精研业务，因为行业内的人员也需要有一个适应工具的过程，这个过程同时也是业务升级的过程，当业务升级到运维工具那个层面，才是开发人员的用武之地。
这里以前面提到的负载均衡为例，一个项目有5000个用户，一台负载服务器，两台生产服务器，运维人员能想出来的方案总归是轮询、IP hash之类的机械化的点子，是涉及不到业务的。而当业务进一步升级，比如5000个用户里有500个角色是领导，4500个角色是普通员工，整个项目的压力都集中在那500个领导上的。既然如此，那就让500个领导一台服务器，4500个普通员工一台服务器吗，这是一个业务主导的主备模式，普通员工服务器崩溃了就是服务器错误。领导的服务器崩溃了可以跳到普通员工的服务器上，作为主服务器，普通员工还是返回服务器错误。。。这里甚至可以有一个复杂的业务逻辑，用一个超级复杂的主备模式来确保各种突发情况下500个领导的服务器环境永远处于最优状态。
当然业务也不可能一直升级，开发人员最终难逃被淘汰的结局，而运维人员则是常青树，无论行业技术再怎么发展，他们都是必需的。
文职的考试结果终于在5.1公布了，笔者得到了一个可以接受的分数，有渺茫的进入面试的机会。在京城严峻的疫情形势下，这无疑是一个令人振奋的消息。付出总会有收获，比如笔者只要在五一期间发布文章，就能够获得劳动节勋章
参考资料:
[1].NET 应用程序体系结构指南
[2]Dapr官方文档
[3]DotNetNuke_百度百科
[4]世界两万英尺范围内，均分布有运维体系架构