微服务发展的历史_微服务架构将死，流式架构为王 —— 关于服务端架构发展趋势的无责任预测...

2019.04.12补充：Flink已经在尝试做这样的架构了

社区福利 | 为什么说流处理即未来？​mp.weixin.qq.com

=================================================================

软件架构发展历史：解放生产力

回顾软件架构发展的历程，我们可以提炼出一个总体的技术发展趋势，那就是每次架构技术的演进，都是为了让后端开发效率越来越高。我们简单的提炼一下：

1）大型机一体化：交互和逻辑全部在一套系统中，号称“大一统”的系统，臃肿、复杂、庞大，系统一般运行在大型机上面；

2）C/S架构：将一体化系统拆分为客户端和服务端，客户端负责交互，服务端负责业务实现，客户端和服务端通过网络交互；

3）分层架构：在C/S的架构上，将服务端拆分为多层架构，每一层聚焦于一类特定的逻辑，不同层之间互相依赖，分层架构基本上解决了单个系统的开发复杂度问题；

4）SOA架构：分层架构解决了单个系统的复杂度，但企业中多个系统之间交互还是非常复杂，主要原因是系统间差异很大，包括开发语言、开发框架、对外协议等，SOA就是为了解决多个系统交互的复杂度而产生的，其通过ESB将异构系统连接起来，避免服务端开发时需要跟各种异构系统直接交互，服务端只需要跟ESB交互即可；

5）微服务架构：SOA架构中的ESB臃肿、庞大、复杂，微服务去掉ESB，将业务拆分为细粒度的服务，服务之间通过制定统一的通信规范进行交互。

微服务：屠龙少年变成了恶龙

微服务是最近5 ~ 8年非常流行的架构模式，而且发展到今天（2018年10），本身微服务架构和实践已经很成熟，但此时我们发现微服务其实本身也有很多问题，微服务当初是大家受不了SOA的ESB庞大和臃肿而提出的解决方案，但经过实践后，其实我们会发现，微服务一样复杂，就像曾经的传说一样：屠龙少年变成了恶龙！

我们简单来看看微服务架构存在的主要问题：

1）服务拆分粒度难以准确把握：拆分太细，开发效率、测试效率、运维效率、系统性能、故障处理会有问题；拆分太粗，达不到微服务的目的；即使当时的架构师判断非常准确，后续业务发展，还是需要继续拆分，每次拆分都是一次较大的系统重构，需要投入很大的人力资源，并且带来很大系统稳定性风险；

2）微服务的基础设施同样庞大复杂：如下是我整理的一个微服务基础设施，可以看到并不简单，基本上相当于把ESB的功能全部实现了一遍：

相信很多非互联网的团队在尝试微服务架构的时候都会深有感触，原本以为只是系统拆分就可以了，后来才发现微服务基础设施才是关键，没有微服务基础设施做支撑，拆分系统相当于给自己挖了大坑！

当然，针对微服务存在的问题，现在又提出了Service Mesh，简单来说，Service Mesh尝试解决微服务的基础设施庞大臃肿的问题，但对于微服务的第一个问题同样解决不了，所以我认为Service Mesh是微服务的改良，算不上一种新的架构，和微服务本质上一样都还是服务拆分。

下一代业务软件架构：流式架构大一统

既然如此，下一代服务端开发架构会是什么样的呢？

我认为服务端真正的架构突破应该做到让服务端开发人员无需关注高性能、高可用、可扩展这些传统架构设计，而只需要关注业务逻辑实现即可。按照这个标准，其实隔壁的大数据架构已经做出了很好的榜样，我们简单回顾一下：

• 最初的Hadoop提供大数据存储的统一架构，屏蔽了大数据存储的分片、备份、故障恢复等架构设计细节，不管什么大数据，不管多大的数据量，Hadoop架构都可以搞定；
• Storm、Flink、Spark提供了流式计算的统一框架，屏蔽了任务定义、数据流、任务重试、高性能等架构细节，不管什么流式计算，按照其规范写就可以运行了；

事实上，在简单研究了Flink的一些原理和用法后，我感觉Flink的架构模式可能就是服务端后续架构演进的方向，即：服务端开发也类似于流式架构，服务端业务开发人员只需要定义每个请求的处理流图，然后提交给类似Flink的系统（为了方便后面描述，我们假设其名称为Slink）进行处理即可。

如下是Flink的架构：

如下是Flink的JobGraph，每个JobGraph对应一个业务处理流程：

这样做有如下好处：

• 服务端开发人员无需再关注系统性能，Slink集群可以用容器动态扩容，Slink集群也可以动态调整某个业务的Task数量；
• 服务端开发人员无需再关注系统可靠性，Slink集群管理Task，包括调度、重启、状态管理等；
• 服务端开发人员无需再考虑系统拆分，因为系统已经拆分到单条业务的粒度了，业务发展和变化，不会导致架构变化，只需要调整业务处理流图就可以了；
• Slink可以支持多个业务运行，资源可以做到最大程度的共享；
• 几乎大部分中间件，例如消息队列、全链路跟踪、配置中心、降级系统等都可以去掉，Slink平台可以内置这些功能；
• 运维基本上维护Slink平台即可，业务无需运维维护；
• Slink可以支持多语言，不再要求服务端开发统一技术栈；

当然，说起来简单，做起来还是挺难的，估计也只有大公司或者开源组织有实力来实现这样一个平台，但我相信服务端架构一定会演进到这一步。

不过，演进到这一步后，对于服务端开发人员来说，不一定是好事，尤其是我这种挂着架构师头衔的，原因你懂得 ：）

======================2018.11.05补充==========================

感谢 @海淀游民 的交流和探讨，他主要的观点是 O LTP系统中的存储高性能和高可用是流式架构无法解决的，这个观点是正确的，流式架构主要解决的是计算高性能和高可用等架构问题，对存储高性能高可用无能无力。

针对存储架构这部分，为了能够达到开发人员无需关注高性能和高可用，其实目前已经有两条路线了：

第一是Hadoop、HBase、ElasticSearch、MongoDB这种集群数据存储，存储系统已经原生支持高性能、高可用、可扩展、可伸缩这些特性，主要集中在NoSQL领域，已经很成熟；

第二是云平台提供的SQL系统，例如阿里云的RDRS(DRDS 概述_产品简介_分布式关系型数据库 DRDS-阿里云)，但目前成熟度和NoSQL相比还差一些，如下是DRDS的宣传介绍（不要完全相信宣传语，哈哈）：

DRDS 高度兼容 MySQL 协议和语法，支持自动化水平拆分、在线平滑扩缩容、弹性扩展、透明读写分离，具备数据库全生命周期运维管控能力。

===========================================================

感谢 @任弘迪 的补充，其中一篇论文有兴趣可以看看：osdi，用rust实现的：

https://www.usenix.org/system/files/osdi18-gjengset.pdf​www.usenix.org