2019。04。12補充：Flink已經在嘗試做這樣的架構了

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

軟體架構發展歷史：解放生產力

回顧軟體架構發展的歷程，我們可以提煉出一個總體的技術發展趨勢，那就是每次架構技術的演進，都是為了讓後端開發效率越來越高。我們簡單的提煉一下：

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實現的：