理想的 service 应用开发模式

业务核心将非常的小，就像 DNA 一样，虽然构成人体这么复杂的结构，但是其实除了 DNA 和一些记忆，肉体都是可有可无，意思是：只要有 DNA+记忆，就可以重建一个人。人与外界的交互，语言的，肢体的，可以理解都有 DNA 根据记忆在控制着人的肌肉。随着科技发展，人类将可以实现替换身体的越来越多的器官，只要大脑🧠和记忆还在，无论人的身体器官如何更换，你还是你，他还是他，你的行为模式得以保留。

同样的道理，一个后台软件系统，核心就是业务代码以及存储。而系统和 mq，db，cache 交互的 sdk 是可有可无的，也可以说是可以完全替换的。我们以前的模式是，要使用 mq，就引入 mq 定义的 sdk，然后调用他设计的 api，然后创建连接，将他的结果反序列化，处理重试，异常。

如今我们有一种新的模式，就是业务自己定义它的交互方式(参考下 retrofit,jpa,myabtis(annotation))，他只需要描述需求：通过定义一个接口。然后再业务中调用这个接口的实例，这样应用的核心就已经 ok。这些可以当做是应用的 DNA，试想一下，我们是完全可以根据这些构建一个运行时的应用：我们解析接口的定义，然后构建一个代理对象，在运行时注入。我们完全可以根据不同环境构建注入不同的对象：比如线下连接线下数据库，线上的话，连接另外一个数据库，甚至都不是一个 mysql，他可以换成了 oracle，甚至是内存的（测试阶段）。

总结起来就是，应用（一个 jar 包，无任何 io sdk 依赖）+runner+config 就可以构建一个运行时的实例。其中 runner 可以由平台提供，runner 背面可以进一步维护很多的基础设施，比如 mq，RDBMS，kv，SearchEngine。如果基础设施要升级只需要 runner 自己进行升级即可，应用本身因为是不依赖这些基础设施的，所以不用升级，甚至，可以做到的是，可以做到空中换轮胎，应用完全不重启，就自动完成了基础设施的替换。