原本心血來潮想從「變化的封裝」和「複雜度的轉移」審視來技術的發展，一不小心考慮了太多內容，故梳理成文
概覽
我個人從業經歷的技術架構演進，是從單機架構開始的，先後經歷了單機、SOA、微服務，以及目前還沒徹底摸清的雲原生。 若從我對技術演進的認知出發，把比單體更早的技術也包含進去，我覺得技術架構的演進，可以分為以下幾個階段：
- 原始分散式 -> 單機
- 單機 -> SOA
- SOA -> 微服務
- 成熟的微服務與雲原生
1. 原始分散式 -> 單機
這個階段的技術演進，我覺得根本上的一個重要原因是“摩爾定律”的影響。
分散式技術的很多理念和實現，其實在上世紀七八十年代就已形成，那時候主要以大型機為主，而且即便是大型機，算力也很有限，要想讓計算機能發揮更大的能力，必然是按水平擴充套件的方式來增強，因此最初的分散式架構、rpc的實現，很早就初步成型。
不過那個時期也正是“摩爾定律”最發光發熱的時期，每18個月算力就能翻倍，這逐漸把計算機的主流由大型機轉向小型機，且小型機的算力足夠支撐業務的發展，由此很多之前需要藉助分散式技術來實現的能力，在單機內就能搞定，這讓單機架構慢慢興起並逐漸成為主流。
單機架構相比於比分散式架構，簡單有效，易於實施，因此應用非常廣泛，時至今日也不乏應用場景。雖然在單機架構下，業務也得到了飛速發展，但只要算力的增長能滿足業務的量級和業務的增長，單機架構就有應用場景。
2. 單機 -> SOA
這個階段的技術演進，我覺得根本上的原因是，業務的進一步激增和“摩爾定律”的逐漸失效。
單機架構居功至偉，擴大了計算機能處理的業務邊界範圍，也逐漸讓業務的量級逐漸超出單機算力能處理的極限，若要平衡算力和業務，讓業務處於算力能處理的範圍內，必然要對業務做分解和分發，讓更多計算機分別處理一部分業務，然後再做整合，這讓架構又開始從單機往分散式演進。
從單機到SOA，我覺得是這個階段里程碑意義的兩點，如果在進一步細分，我覺得可以分為單機->單體，單機（單體）-> SOA 兩個子階段。
2.1 單機 -> 單體
我個人是把單體視為區別於單機的另一種架構的，所謂單機，就是把所有的技術實現，都放到同一臺計算機上，而單體，是基於分層的業務架構的（如MVC），只有同一層的核心業務，需要作為一個整體放到同一臺計算機上，而相對獨立的非核心業務或其他層級的業務，均可以放到其他計算機上。
這裡之所以把單體單獨摘出來，一方面，單體是單機的一種進化，現在依然應用廣泛，另一方面，單體，也是下一代的微服務架構演進的發力點之一，值得在技術演進中提一筆。
單體的主導思想還是單機，且已經有一定的工作分解在其架構中了，但若業務的複雜度更進一步，它依然不能好好的應對，需要有更進一步的里程碑式架構方案來解決問題
2.2 單機（單體）-> SOA
從單機走向分散式的過程中，單體盛行，C/S模式、B/S模式等均是實際應用中的解決方案，但只有SOA的提出，才形成了走向分散式里程碑的解決方案。
SOA既是一種技術架構，也是一種架構思想，它提出面向服務做架構設計，這相容單體、C/S、B/S等實際生產中應用的模式，也意味著系統的功能模組，可以拆分為不同的服務，SOA下支撐多種服務，因此很容易被接受和推廣使用。
另外，除了業務特別複雜讓單機/單體架構的系統不能很好的擴充套件和維護外，隨著技術的發展，業務的普及和推廣，（異構）系統的整合也日益成為業務發展的必然需求，這在單機/單體架構下很難開展，而SOA架構能迎刃而解。
由此，隨著業務的發展，SOA日益盛行。
3. SOA -> 微服務
SOA，既是一種技術架構，也為業務丟擲了一個“面向服務”的概念，因此，在業務視角下，微服務可以看作是SOA的一個子集或一種演化，但從技術視角看，SOA和微服務的底層技術是不相同的，因此在技術演進上來講，微服務是區別於SOA的另一種架構，也是能比SOA更好的應對業務更近一步發展的架構。
SOA作為一種架構思想，雖然在業務視角上看似解決了業務發展中的很多問題，但在技術層面，實際落地時依然有些問題不好解決：
- SOA中的每個服務，可能還是單機或單體服務，服務的可擴充套件性和可維護性良莠不齊
- 服務間的通訊，嚴重依賴匯流排，因此匯流排作為SOA核心基礎設施，特別複雜
- 匯流排通常是SOA中的單點，而匯流排又是核心，這進一步增加了匯流排的技術複雜度
SOA盛行的時代，業務量級上億的系統還是鳳毛麟角，以我對SOA有限的認識看，讓SOA去支撐億級的系統也比較困難。因此不論是面向解決SOA中的技術痛點，還是應對後來的業務量級進一步發展，技術架構必然會走向下一步的技術演進。
微服務就是取代SOA的下一代技術，它對SOA做了進一步的拆解：
- SOA中的服務，可以進一步拆分為更小的顆粒度
- 服務之間可以直接通訊，不再依賴匯流排
- 取消匯流排，拆解匯流排，取而代之的是一系列微服務基礎設施，如服務註冊、發現、限流、監控等
微服務不僅解決了SOA的痛點，也能把物件導向的思想融於其設計，因此單機/單體轉微服務也很方便。
微服務是2012～2014年間提出和興起的，這時分散式的各種理論體系基本成熟，虛擬化技術更加成熟易用，軟硬體基礎設施與生態進一步完善/完備，這都為微服務的興起奠定了基礎。
由此，微服務一經提出，迅速盛行，蓬勃發展至今。
4. 成熟的微服務與雲原生的雛形
微服務發展至今，其理論、架構和生態已經基本成熟和穩定，微服務的完善過程中，也逐步催生了雲原生相關技術，目前雲原生初步成型，以我目前對雲原生有限的認識看，雲原生相當於微服務的另一種實現形式，其後續的發展演化，可能會讓技術架構演化之下一階段，姑且稱之為里程碑意義的雲原生架構，目前雲原生僅是雛形，故暫且把成熟的微服務與雲原生的雛形作為統一技術演進階段。
4.1 成熟的微服務
微服務架構現在是成熟的技術架構，也是能夠應對億級業務規模強大架構，但它同時也是一套特別複雜的架構，它不是銀彈，面向不同的業務量級和業務複雜度，各類技術架構依然存在有效的應用空間。
當前成熟火熱的微服務架構，後續會單獨總結梳理，本節結合我認為當前微服務架構設計和開發中可能存在陷阱，從另一個角度來描述一下對微服務的認識。
現在成熟的微服務，雖然是建立在完善的微服務基礎設施之上，但微服務一直是一個上手門檻不高，精通吃透卻很難的架構體系，這是選型微服務架構時的一個陷阱，開發者有可能會低估微服務的難度。一方面，微服務架構本質上是降低了內部複雜度，增加了外部複雜度，微服務如何拆分，微服務間如何協作很考驗架構師的取捨能力，我們也一不小心就聚焦於它對內部複雜度降低的程度，忽略其對外部複雜度增加的程度；另一方面，微服務對基礎設施的依賴，高併發、高可用、可擴充套件、安全性等技術要求，帶來的分散式情況下的分工協作、併發控制、冪等設計、事務處理、事務補償等實現邏輯，服務限流、降級、監控、追蹤等帶來的新複雜度，都可能會侵入式的改變原有業務邏輯，這些都是微服務架構設計和實現中的難點，也是可能會被樂觀低估的點。
我認為微服務架構的有效應用，需要架構師的重度參與，而這點卻可能會忽視。單機/單體架構，技術專家就能很好的承擔研發工作；其他分散式架構，由於在缺失架構師參與的情況下，可能從一開始就無法很好的開展工作，故架構師的作用不會忽視；而微服務架構，由於在業務早期上手容易，沒有架構師也可能會有效開展，但隨著業務複雜度和量級的發展，沒有架構師的把控可能會讓系統開發變得越來越吃力，另外開發者可能被微服務的潮流裹挾，在架構設計未經充分評估權衡的情況下，直接無腦錯誤選型微服務；這些都是微服務開發中另一個潛在陷阱帶來的問題。
4.2 雲原生的雛形
微服務的邏輯需要對應的成熟基礎設施，當微服務的基礎設施不在應用層的微服務框架提供，而是轉向基礎設施層提供時，這種微服務，就成了雲原生微服務。
當雲原生相關的技術和生態完全成熟後，微服務技術框架中面向微服務基礎設施的複雜度，會轉移到雲原生基礎設施上去，且複雜度轉移後，應用層微服務的開發更簡單，基礎設施上的複雜度，對微服務業務的開發幾乎是無感的，效能也會有一定程度的增強，那時，我們可以把雲原生作為技術架構從微服務進一步演進的下一代技術，而當前，雲原生的技術生態尚未成熟，技術設施上的複雜度依然暴露在微服務開發者的視野下，故暫時把雲原生技術視為實現微服務架構的另一種方式。
5. 總結
- 技術的發展，也是分久必合，合久必分的，我覺得這期間一個不變的主線，是對變化的封裝和對複雜度的轉移。
- 當算力強於業務發展時，將複雜度封裝和轉移到單機中，單機內部複雜度增加，而外部應用的複雜度降低，推進了技術的演進和業務的發展；
- 當算力的增長無法讓單機處理激增的業務時，會對業務做工作分解和分配，把原本在內部的複雜度又轉移到外部，讓算力得以應對分解後到業務；
- 以往技術的發展，是在封裝和轉移複雜度，帶來了這幾十年的技術架構演進，以後的技術，將會帶來封裝和轉移複雜度的新方式，從而推進技術架構未來的演進。
- 複雜度不會消失，只能被轉移，外部複雜度的降低必然帶來內部複雜度的提升，反之亦然。每一代的技術架構，無非是找到了內外部複雜度變化的平衡點，並提供了技術落地實現和維護使用行之有效且提高效率的手段。
- 技術和業務的發展相輔相成，技術的發展帶來新的生產力，擴大了業務的量級和邊界，帶來新的業務模式，業務的發展和創新也倒逼技術的革新和進步；技術架構的演進與業務發展密不可分
- 正是由於複雜度不會降低，只會轉移，新舊技術間是有藕斷絲連的關係的，搞清楚經典的技術理論，也利於迅速掌握新技術的本質（如單機多核時代的併發理論，同樣可以借鑑到微服務的併發與同步中）
What's More
歡迎查閱本文的微信公眾號連結，歡迎關注我的公眾號～
注：轉載本文，請與Gevin聯絡
歡迎關注我的微信公眾賬號
