服務架構進化論
- 原始分散式時代
一直以來，我可能和大多數的人認知一樣，認為我們的服務架構的源頭是單體架構，其實不然，早在單體系統盛行之前，我們的前輩們就已經探索過使用多個獨立的分散式服務共同完成一個大型的系統的實現方案。
眾所周知，計算機的伊始是一個龐然大物，大概需要一整間屋子才可以容得下它那巨大的身軀。後來到了20世紀70年代末，計算機終於被聰明的科學家們設計再設計，搖身一變成了微型機，可以擺放在桌子上的那種。可這時候的微型計算機仍然屬於它的時代的嬰兒期，它沒有我們想象中的高速的運算能力，它通常只有16位定址能力、不足5MHz的時脈頻率和128KB的記憶體空間，這種有限的運算處理能力直接限制住了單臺計算機上可以執行的系統的規模，根本不利於我們來開發出一個理想的業務系統。
為了解決單個計算機處理能力有限的問題，聰明的科學家們想出了一個分而治之的好方法，一臺我們不夠用我們就搞兩臺，兩臺不夠用我們搞10臺，大問題拆解成小問題，大系統拆解成小系統讓他們互相配合麼，這不就解決了。想法確實不錯只可惜出現的時代不對，我就想說一句：泰勒公式你找一個嬰兒推理不出來，那找10個嬰兒讓他們互相商量商量就能推匯出來了？
前輩們從來不只是說說而已，搞分散式那可是真的搞，於是早期的IT泰山北斗們開始浩浩蕩蕩的幹起來了。大家一塊制定“分散式運算環境”(DCE)的分散式技術體系,包含了一些遠端呼叫規範、分散式檔案系統、服務認證規範、時間服務及明明目錄服務等等，甚至如今我們IT行業最熟悉不過的UUID也是在DCE中發明出來的，可以說DCE是現代分散式的一個鼻祖。
搞分散式自然少不了遠端呼叫，可是對於當時的計算機硬體水平來講，一旦加上遠端兩字，那執行時間是呈幾何式的倍數增長，效率也大打折扣，況且對於服務的一些發現、負載均衡、服務熔斷隔離降級等問題都沒有一個十分完善的解決方案，就像我提到的那樣，我們的微型計算機伊始就像一個嬰兒一樣，它太弱小了，弱小到根本沒有足夠的能力支援它和其他的計算機很好的去配合。至於如何去構建大規模的軟體系統，要麼就是儘快提升單機的處理能力，要麼就是找到一條更完美的解決構建分散式系統的方案。
探索從未停止，但是原始的分散式時代高歌幾年卻終究沒有盛行起來。
2.單體系統時代
單體架構算是大家最熟悉的一種架構了吧，基本每個開發者在學習時，都會去實踐的一種架構。仔細想來，我從工作到現在還真沒搞過單純的單體架構，開始兩年整的SOA，這兩年一直是微服務。不過拋開整個大型系統來講，單純的看微服務架構中的某個服務，這也可以稱得上是一個增強版的單體架構吧，只不過多了些服務註冊了、feign遠端呼叫了、包的結構設計更加趨於現在風格，主體業務程式碼的編寫感知上和單體系統並無很多差別。當然放在整體系統來講，那差異確實大了，單體系統將所有的模組功能都放在這個一個服務裡，耦合度比較高，而微服務卻拆分出來了，每個模組的職責比較明確，每個模組自成一個服務，很好的詮釋了弱耦合、高內聚的概念。
自從20世紀80年代後，摩爾定律開始穩定發揮作用，計算機的效能以每兩年一倍的驚人速度提升，我們的資訊還沒有像今天一樣呈爆炸式增長，也沒有那麼多如今的各種高流量高併發的大規模場景，單臺伺服器或者少量幾臺伺服器足可以支撐起大型資訊系統的運作，於是單體系統時代來了，它足足佔據主流地位了30年，放在如今很多小公司小系統也不乏有很多使用單體架構的。
單體系統到底是什麼？從整體概念來看，他無非就是一個人也可以活得像一支隊伍，好比如今我們的電商系統，可能大家都選擇將使用者模組、訂單模組、支付模組、商品模組等等拆到不同服務中去執行，各司其職，有用得到對方的去呼叫一下，但是單體系統不會這樣幹，它就喜歡獨掌大權的感覺，上文所述的眾多功能它全自己一個人來搞定，有我一臺服務就夠了，絕對不會像其他服務通訊求救，要是其中某個功能出了問題，我們大夥一塊全下線；從架構劃分上，單體架構內部的管理也是有模有樣的，像我們最熟悉的MVC架構、SSM組合拳，通常不就是劃分為了Controller表示層、Service業務層、Mapper持久層、DataBase資料庫層。它的問題排查與運維成本通常也比我們如今盛行的微服務小很多，畢竟就一個服務在那，出了問題很明顯就是它的錯。
雖然說單體架構有自己的侷限性，但不可否認我們如今新興的所有架構都是在它的基礎上演變來的。
3.SOA時代
關於SOA架構，坦白講，這是我最沒信心講明白的一個架構了，因為從這幾年的經歷來講，總感覺他沒有一個很系統的架構模式的定義，說他是單體但是他已經存在多個服務屬於分散式了，說他是微服務總感覺還差點意思，沒有劃分那麼微小的粒度，雖說我工作前兩年時同事告訴我我們使用的是SOA架構，但事實上，我當時對架構二字沒有那麼大的感知，能開發能寫程式碼不就行了，接下里我就談下我的一些不成文的淺陋認知，假設不對的地方還請多多包涵，批評指出。
SOA其實就是面向服務的架構，它對於服務的封裝性、自治性、松耦合、可重用性有清晰的指導規則，它要求每個服務更具體更系統，與其說他是一套架構，倒不如說SOA是一套思想，每個公司可以根據自己的業務場景，按照它的指導思想去開發屬於自己的系統架構，在這裡我想談兩種架構的設計方式，大家也可以評估下是否可以歸為SOA架構的範疇。
第一種大概是我19年-21年一直在經歷的一種架構模式，開發技術就是SpringBoot + SpringData JPA，服務劃分大概分為了基礎服務、業務系統服務、定時服務三個服務，基礎服務大概就是涵蓋了一個系統最基礎的那些功能模組：許可權、角色、使用者、審批流等等，每個功能模組用分包的方法區分開；而業務系統服務則是包含了各種業務性的功能，功能模組還是蠻多的，這裡為了保密也就不展開說了，當時每個功能模組的區分方式一樣也是分包路徑的處理的；定時服務也是將所有的job加到這個服務裡來開發。然後當時整個專案當時是沒有註冊中心的，也沒有閘道器，也沒有配置中心，服務之間的呼叫的透過feign-url的方式進行，比較優秀的一點它還引用了seata做了分散式事務的管理，每個服務有自己的DB，可以說這個系統確實是一個分散式的系統了，但是歸為微服務還是欠缺點火候的，畢竟那些眾多的業務模組並沒有單獨的劃分出來自成一個服務，一個的功能模組出問題其餘的也多少受影響的，不過也確確實實的算是面向服務開發了，所以將它歸為SOA的範疇我覺得也是有些道理的。
第二種呢是我平時看一些學習影片提到的,它是一個標準的垂直劃分的架構，自上而下分別拆分為了應用層、業務服務層、基礎業務層、基礎服務層、儲存層。應用層也叫作接入層，只負責接收來自於使用者的請求，不會直接訪問DB，透過請求下游服務的介面來處理資料；業務服務層主要是用於處理各種業務場景，比如招聘網站的話就是處理一些職位搜尋，簡歷投遞一類的業務；而基礎業務層則是處理一些系統最基礎的核心功能，像招聘網站的職位管理、簡歷管理、可以為上游的業務服務層提供一些api的支援；基礎服務層則是一些業務無關的模組，用於管理一些訊息推送、附件解析、定時任務，這個服務的特點則是請求量大、邏輯簡單、功能獨立；而儲存層則就是一些mysql、mongodb、Es一類的。整個系統呢引用了Dubbo及zookeeper來完成服務的治理的。
其實從服務拆分來看，第二種比起第一種來講只是把controller應用層單獨拆出了一個服務，其餘的拆分手法還是蠻像的。從技術來看，第一種不含註冊中心，而第二種卻使用了zookeeper來充當了註冊中心。二者有共性也有差異，但總歸來想，都是往拆分服務的方向看齊，確實比起單體架構發生了質的改變。
4.微服務時代
微服務大概是目前正在流行的一種服務架構了，多少曾經的SOA架構擁護者也慢慢的向微服務靠攏，從概念上來講，微服務是一種透過多個小型服務組合來構建單個應用的架構風格，這些服務圍繞著業務能力而非特定的技術標準來構建。各個服務可以採用不同的程式語言、不同的資料儲存技術、執行在不同的程式中，服務採取輕量級的通訊機制和自動化的部署機制來實現通訊與運維。
《鳳凰架構》一書提到，微服務有九個核心的業務與技術特徵，分別是：圍繞業務能力構建、分散治理、透過服務來實現獨立自治的元件、產品化思維、資料去中心化、強終端若管道、容錯性設計、演進性設計、基礎設施自動化。通俗來講，就是要我們根據業務場景來進行顆粒度的服務拆分，每個微服務又自成一個可以獨立執行的系統，可以分散不同人來管理，服務之間的通訊儘可能的簡單快捷，要考慮到擴容性和容錯效能，由於一個系統拆分為眾多的微服務所以在部署時也要完成自動化的構建，減少不必要的人為操作，以防等待時間過久或操作失誤。
關於微服務系統的技術實現，我們通常使用第一代springcloud的元件或者使用第二代Springcloud alibaba的各種元件來實現，第一代springcloud元件比較盛行的是：eureka服務註冊中心、ribbon負載均衡、hystrix熔斷器、feign遠端呼叫元件、zuul閘道器、spring cloud config分散式配置中心、spring cloud stream訊息驅動元件。而第二代比較盛行的是nacos服務註冊與配置中心、gateway閘道器元件、Sentinel流量控制熔斷降級元件、seata分散式事務管理元件。當然，二者的使用大可不必將界限劃分那麼清楚，沒必要一套系統我使用第一代的就不使用第二代了，也沒必要為證明自己是搞得微服務就將所有元件堆砌而上，還是具體場景具體分析，就像我平時工作中一樣，可能註冊中心使用的eureka，而配置中心卻用了nacos，閘道器則用了gateWay,遠端呼叫則使用了feign。
微服務其實追求的是更加自由的架構風格，它拋棄了SOA中的那些條條框框的約束，用實踐為標準代替了規範的約束。但這裡我想講的是，並不是所有的系統都適合微服務，也是真的沒必要無腦的往微服務靠攏，一個系統能用簡單的方式應對，那完全沒必要耗費資金人力去拆分出各式各樣的小服務來彰顯自己的技術內涵，呼叫鏈路真的越短效率越高也不易出錯。在這裡我深有體會，前兩年搞SOA時，其實公司真正經常改程式碼的也就業務服務和基礎服務兩套，所以每次出問題能很快的定位到並解決，現在整這個微服務，整個大系統的微服務就有幾十個，有很多服務由其他同事管理而我自己並不熟悉，但是平時還需要呼叫他們提供的api,每次出現問題可能得拉會好幾個同事一塊討論，問題解決難度增大了，而且上線時好多服務要理清楚上線順序和程式碼，生怕哪個服務忘了上線整出問題來。之所以很多公司需要使用微服務是因為自身的業務系統愈來愈複雜、流量越來越多、資料資訊變成海量才不得不去使用微服務的手段來應對，但是你的系統單一未來也很明確不會加入複雜的場景，那還是建議你保持初心吧。
5.後微服務時代
微服務時代可以說是被Spring Cloud統治的時代，分散式架構中出現的註冊發現、跟蹤治理、負載均衡、傳輸通訊，我們總能在Spring cloud提供的元件中找到一個解決方案，但是這些解決方案都是軟體的形式來提供的。不妨想一下，我們可不可以不侷限於軟體的方式，而考慮下硬體的解決方案呢？
事實上，Kubernetes提供了一套基礎設施層面的解決方案，下面將展示下與傳統的第一代springcloud的解決方案的對比：
|
|
Kubernetes |
Spring Cloud |
|
彈性伸縮 |
Autoscaling |
|
|
服務發現 |
KubeDNS/CoreDNS |
Spring Cloud Eureka |
|
配置中心 |
ConfigMap/Secret |
Spring Cloud Config |
|
服務閘道器 |
Ingress Controller |
Spring Cloud Zuul |
|
負載均衡 |
Load Balancer |
Spring Cloud Ribbon |
|
服務安全 |
RBAC API |
Spring Cloud Security |
|
跟蹤監控 |
Metrics API/Dashboard |
Spring Cloud Turbine |
|
降級熔斷 |
|
Spring Cloud Hystrix |
Kubernetes的整套解決方案得益於這些年虛擬化技術和容器化技術的發展，當虛擬化的基礎設施從單個服務的容器擴充套件到多個容器構成的服務叢集、通訊網路和儲存設施時，軟體與硬體的便已模糊。一旦虛擬化的硬體能夠跟得上軟體的靈活性，那麼與業務無關的技術性問題便能從軟體層面玻璃，悄無聲息的在硬體基礎設施之內解決，讓軟體只專注於業務，真正的圍繞業務能力來構建團隊於產品。
Kubernetes在容器生態發展中的嶄露頭角標誌著後微服務時代的到來，但是它仍然有自己的缺點，很多場景的特殊性可能我們透過軟體的手段很容易就解決了，但是在硬體層面，它針對於整個容器來管理時粒度比較粗的，很多時候難以做到有效的管控，但是我們仍然可以相信，隨著Kubernetes的不斷完善和進化，它會成為服務端的標準執行環境，它將會慢慢的可以取代今天Spring Cloud全家桶中大部分的元件的功能，微服務只需要考慮自身的業務本身的邏輯，這將是智慧終端的最終解決方案。
6.無服務時代
談到無服務時代我們不得不提起一個圈內耳熟能詳的的詞 ---- 雲端計算。百度百科上是這樣介紹雲端計算的：雲端計算（cloud computing）是分散式計算的一種，指的是透過網路“雲”將巨大的資料計算處理程式分解成無數個小程式，然後，透過多部伺服器組成的系統進行處理和分析這些小程式得到結果並返回給使用者。雲端計算早期，簡單地說，就是簡單的分散式計算，解決任務分發，並進行計算結果的合併。因而，雲端計算又稱為網格計算。透過這項技術，可以在很短的時間內（幾秒鐘）完成對數以萬計的資料的處理，從而達到強大的網路服務。現階段所說的雲服務已經不單單是一種分散式計算，而是分散式計算、效用計算、負載均衡、平行計算、網路儲存、熱備份冗雜和虛擬化等計算機技術混合演進並躍升的結果。雲端計算指透過計算機網路(多指因特網)形成的計算能力極強的系統，可儲存、集合相關資源並可按需配置，向使用者提供個性化服務。
有些專家預言：無服務將會成為未來雲端計算的主要形式。由於雲端計算將很多複雜的架構設計和難點處理全權託管到雲端伺服器來處理，因此對於開發者來講，完全就不需要來考慮技術元件了，因為元件是現成的；不需要考慮部署了，部署託管到了雲端；不需要考慮算力了，有整個資料中心支援著；不需要考慮運維了，有云計算的服務商幫你搞定。我們開發者僅僅需要純粹的關注業務就好了。
不管是SOA架構還是微服務架構，相比起最初的單體架構來講，架構形式好像愈來愈複雜了，對開發者的技術要求也特別高，而無服務，則是向簡單發展，複雜的部分都託管向雲端，未來若它成為大流行，那麼所需的可能是業務極強的開發者，而不是單純的技術牛人了，無服務它只涉及兩塊內容：後端設施（Backend）和函式（Function）。
後端設施是指資料庫、訊息佇列、日誌、儲存，等等這一類用於支撐業務邏輯執行，但本身無業務含義的技術元件，這些後端設施都執行在雲中，無服務中稱其為“後端即服務”（Backend as a Service，BaaS）。
函式是指業務邏輯程式碼，這裡函式的概念與粒度，都已經很接近於程式編碼角度的函式了，其區別是無服務中的函式執行在雲端，不必考慮算力問題，不必考慮容量規劃（從技術角度可以不考慮，從計費的角度你的錢包夠不夠用還是要掂量一下的），無服務中稱其為“函式即服務”（Function as a Service，FaaS）。
坦白講，至於它今後的一個運作方式我也無法具體描述，這種模式也在積極的探索中，至今並沒有一個準確的落地實現，不管如何，社會對於程式設計師的要求也僅僅不是技術那麼簡單了，做一名懂業務的程式設計師才是大勢所趨。
後言：上述的很多觀點一方面是自己總結的，另一方面是看的《鳳凰架構-構建可靠的大型分散式系統》一書借鑑來的，不得不說，這本書真滴厚，周志明老師是真滴強。這是我讀這本書的第一篇心得，希望自己能在忙碌的工作生活中能堅持繼續將這本書讀完，寫出更多的心得。