数据亲和架构--缘起

         数据亲和架构并没有否定其他架构，尤其是微服务架构的合理性，而是从另外一个视角来重新审视整个架构，做出补充。让数据和业务逻辑具备更强的亲和性，故命名为数据亲和。

        微服务架构提出了一个理念，每个服务划分成更细粒度的服务单元。每个单元的职能更加单一，降低了服务单元的复杂度和耦合性，但它同时增加系统整体复杂度，对运维体系提出更高的要求。

        K8S和Docker解决服务在失效或者高负载情况下，如何调度到一个可用的环境，并重启。Dapper解决了链路监控的问题，确保随时感知整个系统的健康度。这些组件解决了微服务架构的运维层面问题。

        但是从业务服务的实现角度来看，情况并没有得到太大改善。从一个具体的业务服务实现过程来看，基本是接收其他地方的数据，处理数据，管理数据，响应请求并返回结果集。业务数据和业务逻辑是业务服务的两个根本要素，但在微服务架构中，并没有涉及这个问题，只是将他们视为一个黑盒子单元。

        在微服务架构中，因为调用链变长，进程数增多，导致业务数据的恢复、同步、一致性等问题，变得更加严重。

        数据亲和架构，试图用更通用性的方法，管理微服务中本地数据和外部数据的关联问题，解决微服务架构实践到业务服务单元的最后一公里问题。