從單體架構到微服務，今天我們從架構師的角度來談談微服務的前世今生
單體架構
任何一個網站在發佈初期幾乎都不可能立馬就擁有龐大的用戶流量和海量數據，都是在不停
的試錯過程中一步一步演變其自身架構，滿足其自身業務。
比如現在能夠抗住雙十一這麼大流量的淘寶，它的技術最早用的是 LAMP（Linux+Apache+Mysql+Php）.
實際上，架構越複雜，意味著業務的體量越龐大。
對於一個剛剛起步的項目，我們會選擇最簡單最快速的方式來實現。而單體架構是最好的選擇，目前很多的傳統軟件行業仍然採用這類的架構。
一般的實施方案是，把所有的功能模塊都打包在一個（jar、war），並且部署在一個 web 容器下，比如 tomcat、weblogic、jboss 中運行
集群架構
一旦用戶量以及流量開始增加，服務器的性能就會遇到瓶頸，這個時候必須要對系統架構做調整以及優化。
而在這個階段主要需要解決的問題是提升業務系統的並行處理能力，降低單機系統負載，以便支撐更多的用戶訪問操作。
集群就是一種很好的方式，它可以把多臺獨立的服務器通過網絡連接進行組合，對外形成一個整體提供服務。
當一臺服務器的處理能力接近或已超出其容量上限時，我們不會去嘗試換一個更高性能的服務器，因為投入產出比不高，一般的做法就是採用集群技術，通過增加新的服務器來分散併發訪問流量，只要業務系統能夠隨意支持服務器的橫向擴容，那麼從理論上來說就應該無懼任何挑戰，從而實現可伸縮性和高可用性架構。
業務垂直化拆分
雖然通過集群可以提升並行處理能力以及對於高可用的實現，但是同時還需要考慮到業務的複雜度，如果仍然把所有的業務邏輯全部耦合在一起放在一個 war 包中來管理，那對於代碼的維護和擴展來說是非常困難的。
而且如果某個業務功能出現故障，會導致整個系統不可用。所以這個階段要做的就是降低業務的耦合度，提升系統的容錯性。
所以這個時候可以對業務進行垂直化拆分，簡單來說，就是可以按照系統的業務功能拆分出多個業務模塊，比如電商網站，會拆分出：首頁、用戶、搜索、訂單、支付、商品等子系統。
每個子系統由不同的業務團隊負責。
服務化改造
隨著對業務系統進行垂直化改造之後，以業務功能緯度拆分出來多個子系統，而在各個子系統中，會存在比較多的共享業務，比如用戶信息查詢，在支付業務中會涉及到、在首頁中也會涉及到。
那麼勢必會造成重複開發產生非常多的冗餘代碼。那麼這個時候就引入了服務化改造的思想，也就是 SOA把一些通用的、會被多個上層服務調用的模塊獨立拆分出來，形成一些共享的基礎服務。
這些被拆分出來的共享服務相對來說是比較獨立，並且可重用。比如用戶管理服務，包含用戶註冊、用戶查詢等功能。比如單點登錄服務。
SOA 的核心目標就是通過服務的流程化來實現業務的靈活性，而這個流程化其實就是一系列相關聯的任務組成，這一系列相關聯的任務可以通過一系列的服務組合來實現具體的業務功能。
SOA 面向服務架構，從語義上說，它與面向過程、面向對象、面向組件一樣，是一種軟件組建及開發的方式。所以在 SOA 中，服務是最核心的抽象手段，業務被劃分為一些列粗粒度的業務服務和業務流程。
SOA 中更強調 ESB 企業服務總線，企業服務總線可以使得服務之間的交互是動態的，以及服務位置是透明的。這樣的好處是服務的調用者和服務的提供者之間是高度解耦的。從而使得服務有更高的靈活性以及隔離性。
ESB：是從面向服務架構(SOA)發展過來的，主要是對多個系統中的服務調用者和服務提供者的解耦。
ESB 本身提供了服務暴露、接入、協議轉化、數據格式轉化、路由等功能。
SOA 主要解決的問題：
- 信息孤島
- 互聯互通
- 業務重用
微服務架構
業務系統實施服務化改造後，原本共享的業務被拆分，形成可複用的服務，可以在最大程度上避免共享業務的重複建設、資源連接瓶頸等問題出現。那麼那些被拆分出來的服務，是否也需要以業務功能為維度來進行拆分，使之能夠獨立進行部署，以降低業務藕合和提升容錯性呢？
微服務並不是一種新思想的方法。
它更像是一種思想的精煉，是一種服務化思想的最佳實踐方向而已，所以我認為微服務其實是在 SOA 思路下，隨著各個企業對於服務化治理上不斷的完善，以及對軟件的交付鏈路以及基礎設施逐步成熟之下的一種自然的產物。
微服務也是一種面向服務的架構模型，只是它更強調服務的粒度。也就是服務的職責更加單一更加精煉我們也可以把 SOA 看成是微服務的超集。也就是多個微服務可以組成一個 soa 服務。
微服務和 SOA 架構的區別
經常會有同學問，微服務和 SOA 架構有什麼區別。這個區別一定要從架構的發展過程來了解。
這兩種架構模式，其實本質上應該是在分佈式架構這條時間線上，基於服務化思想的不斷完善，以及基礎設施的逐步成熟之下的一種升級。既然存在於時間線的先後，那也就意味著，這兩種架構模式所關注的點不一樣：
- SOA 關注的是服務的重用性、以及解決企業內部的信息孤島問題
- 微服務關注的是解耦，解耦和可重用性在特定的角度來看是一樣，但本質上是不同的。解耦是降低業務之間的耦合度（也就是微服務關注的服務粒度），而可重用性關注的是服務的複用
- 微服務會使用更輕量級的通信協議，使用 Restful 風格的 API。輕量級協議可以很好的支持跨語言，使的語言生態更加豐富
- 微服務會更多的關注 Devops 的持續交付，因為服務粒度更細使得開發運維變得更加重要。
- 所以微服務對於容器化技術的結合更加緊密
- SOA 應該是微服務的超集
Spring Cloud 生態
提到微服務技術體系，大家第一個想到的應該是 spring-cloud。那麼什麼是 SpringCloud 呢？
微服務架構的實施現狀
我最早接觸微服務是在 15 年，公司內部當時使用的是 Dubbo 這一套架構，然後開始圍繞spring -boot 這個微框架進行微服務體系的探索和實施，基於 spring-boot+dubbo 來構建微服務而現在，微服務相關的技術生態以及社區都很成熟了，所以很多公司也都逐步往微服務體系進行轉型。
我們來了解一下微服務的技術生態
什麼是 Spring-Cloud
我們知道 spring cloud 可以用來開發微服務，但是應該很少有同學真正知道 spring cloud 是什麼。
官方的解釋是：spring cloud 提供了一些可以讓開發者快速構建分佈式應用的工具，這些服務可以很好的工作在任何分佈式環境下。
既然提供的是一些快速構建微服務應用的工具，那麼我們需要了解微服務開發過程中需要解決哪些問題？
網關
在微服務實施之後，各個服務的拆分粒度很小，對於客戶端來說，做一個操作可能會涉及到後端的多個服務組件的調用，那意味著它需要頻繁的發起多次訪問才能進行數據聚合實現用戶的功能。
如果我們在所有的微服務之前增加一個網關，對於客戶端來說它需要做什麼功能操作直接調用網關並且告訴網關所要做的事情即可，網關根據請求的功能對後端的多個服務的數據進行聚合從而減少客戶端的調用頻次。
並且，由於有了網關的聚合，我們還可以在網關層對請求進行統一鑑權和認證；包括還可以實現限流、請求日誌統一記錄、 灰度發佈等等。
服務的通信和服務發現
服務拆分以後就會涉及到服務的遠程通信，比如 http 協議或者 rpc 協議。在滿足基礎通信的基礎上，如何做到服務的統一管理以及服務的動態感知，就需要涉及到服務的註冊中心來實現服務註冊和發現的功能
負載
假設服務提供者為了擴大吞吐量，採用 10 臺機器的集群部署，這個時候客戶端從註冊中心獲得服務以後，應該調用哪臺機器呢？
所以必然有一種負載均衡的機制，來實現客戶端請求的分發。
熔斷、限流、降級
在分佈式架構中，各個服務節點一定需要滿足高可用，所以對於服務本身來說，一方面是在有準備的前提下做好充足的擴容。另一方面，服務需要有熔斷、限流、降級的能力。
當一個服務調用另外一個服務，可能因為網絡原因、或者連接池滿等問題導致頻繁出現錯誤，需要有一種熔斷機制，來防止因為請求堆積導致整個應用雪崩。
當發現整個系統的確負載過高的時候，可以選擇降級某些功能或某些調用，保證最重要的交易流程的通過，以及最重要的資源全部用於保證最核心的流程。
在設置了熔斷以及降級策略後，還有一種手段來保護系統，就是限流算法。
我們能夠通過全鏈路壓測瞭解到整個系統的吞吐量，但實際上的流量可能會超過我們預期的值，比如存在惡意攻擊、或者突然的高峰流量。在這種情況下可以通過限流來保護系統不崩潰，但是對於部分用戶來說，會出現被限流導致體驗不好的情況。
統一配置中心
服務拆分以後，服務的數量非常多，如果所有的配置都以配置文件的方式放在應用本地的話，非常難以管理，可以想象當有幾百上千個進程中有一個配置出現了問題，是很難將它找出來的，因而需要有統一的配置中心，來管理所有的配置，進行統一的配置下發。
在微服務中，配置往往分為幾類，一類是幾乎不變的配置，這種配置可以直接打在容器鏡像裡面，第二類是啟動時就會確定的配置，這種配置往往通過環境變量，在容器啟動的時候傳進去，第三類就是統一的配置，需要通過配置中心進行下發，例如在大促的情況下，有些功能需要降級，哪些功能可以降級，哪些功能不能降級，都可以在配置文件中統一配置。
微服務架構下的組件需求
下面是基於一個請求進來之後，所需要用到的組件和功能
從圖可以看到，如果要實施微服務，我們需要解決很多的問題，比如
- 服務註冊發現
- 遠程服務調用
- 負載均衡
- 斷路器
- 分佈式消息
- 配置中心
- 鏈路監控
所以， spring cloud 提 供 了 一 些 解 決 這 類 問 題 的 工 具 。
比 如 服 務 注 冊 提 供 了Eureka/Consoul/zookeeper；
遠程調用基於 RestTemplate 針對 http 協議調用的封裝；
負載均衡採用 Ribbon、斷路器採用 hystrix；
分佈式消息基於 kafka、rabbitMQ；
配置中心基於config;
鏈路監控基於 sleuth.
但是，從這些組件中，我們發現了一些問題，這些組件並不是 spring 提供的啊，比如 eureka、ribbon、hystrix 是 netflix 開源的。而 kafka、zookeeper 是一些獨立的組件，和 spring 似乎沒有關係。
沒錯，這就是 spring 團隊的強大之處，他們很少重複造輪子，而是他們利用別人造好的輪子來進行封裝使得用戶在使用的時候更加方便。
舉個簡單例子，比如最早 spring 只提供了 IOC 和 AOP 的核心功能，而像 ORM 框架、緩存、MVC 框架，spring 只是提供了一種兼容以及支持，所以當時大家說 spring 是萬能膠，可以把各種各樣的框架整合進來。
當然，spring 也會對一些市面上做得不好的技術進行替代，比如 struts2.，我記得當時公司使用struts2 經常出現各種漏洞，所以 spring mvc 才被創造出來並且很快代替了 struts。成為現在的主流框架。
所以，對於 spring cloud 來說也是如此，spring cloud 並不是一個框架，因為 Spring Cloud的核心並沒有實現服務註冊、熔斷、配置中心等功能，它提供了一個標準規範。
而 Spring Cloud Netflix 才是 spring Cloud 規範的一種實現。
Spring Cloud 生態的構建
Spring Cloud 的生態是基於 spring boot 這個微框架來構建的，所以 spring cloud 可以說是基於 spring boot 來對其他框架進行整合，那麼什麼是 spring boot 或者為什麼要基於 spring boot 來整合呢？
首先，spring boot 並不是一個新的技術，它是基於 spring 框架下對於“約定由於配置(Convention Over Configuration)”理念下的產物，主要是幫助開發人員更容易更快速的創建獨立運行和產品級別的基於 spring 框架的應用。
為什麼說 springboot 是微框架呢？
如果大家玩過 springboot，那應該很有體會，我們只需要非常少的配置就可以快速構建一個 web 項目。
而 spring boot 中並沒有新的技術，如果大家對 spring 框架比較熟悉，那麼在學習 springboot的時候會更加容易。
圍繞 springboot 構建的 spring cloud 生態下，目前有兩類的比較或的實現，一個是基於 netflix、另一個是基於 alibaba。
spring cloud netflix
spring cloud netflix，實際上就是基於 netflix 公司的開源組件，然後基於 spring cloud 的標準規範，在 springboot 的基礎之上進行整合。
Spring Cloud 版本支持
Spring Cloud alibaba 在 2019 年 4 月 19 號，發佈了兩個版本，分別是 0.2.2.RELEASE、0.9.9.RELEASE，分別對應 Spring Cloud Finchley 和 Greenwich.
由於 Spring 官方宣佈對於 Spring Cloud Edgware 在 2019 年 8 月 1 號以後停止維護，所以Spring Cloud Dubbo 並沒有對 E 版本提供支持
在下面這個網址可以看到 Spring-Cloud 的版本支持，它並不像傳統意義上的版本命名，而是採用了倫敦地鐵站的名稱，根據字母表的順序來對應版本時間順序
spring.io/projects/spri
原因是 Spring Cloud 是由多個獨立項目組成的整體項目，而每個獨立的項目有不同的發佈節奏，各個子項目都維護著自己的發佈版本號。Spring Cloud 通過一個資源清單 BOM（Bill of Materials）來管理每個版本的子項目清單。
為避免與子項目的發佈號混淆，所以沒有采用版本號的方式，而是通過命名的方式。
比如：最早的 Release 版本：Angel，第二個 Release 版本：Brixton，然後是 Camden、Dalston、Edgware、Finchley 、到目前的最新版本 Greenwich當一個版本的 Spring Cloud 項目的發佈內容積累到臨界點或者解決了一個嚴重 bug 後，就會發佈一個“service releases”版本，簡稱 SRX 版本，其中 X 是一個遞增數字。
當前官網上最新的穩定版本是 Edgware.SR2，里程碑版本是 Finchley.SR2。
下面這個表分別對應的是 Edgware.SR6 和 Finchley.SR2 對應各個子項目的版本號。
➢ 對於 SpringBoot 版本的兼容如下
- Greenwich 和 Spring Boot 2.1.x 兼容
- Finchley 和 Spring Boot2.0.x 兼容，不支持 Spring Boot 1.5.x
- Edgware 和 Spring Boot 1.5.x 兼容
常見的服務組件
➢ 融合在每個微服務中、依賴其它組件併為其提供服務。
Ribbon，客戶端負載均衡，特性有區域親和、重試機制。
Hystrix，客戶端容錯保護，特性有服務降級、服務熔斷、請求緩存、請求合併、依賴隔離。
Feign，聲明式服務調用，本質上就是 Ribbon+Hystrix
Stream，消息驅動，有 Sink、Source、Processor 三種通道，特性有訂閱發佈、消費組、消息
分區。
Bus，消息總線，配合 Config 倉庫修改的一種 Stream 實現，
Sleuth，分佈式服務追蹤，需要搞清楚 TraceID 和 SpanID 以及抽樣，如何與 ELK 整合。
➢ 獨自啟動不需要依賴其它組件，單槍匹馬都能幹。
Eureka，服務註冊中心，特性有失效剔除、服務保護。
Dashboard，Hystrix 儀表盤，監控集群模式和單點模式，其中集群模式需要收集器 Turbine
配合。
Zuul，API 服務網關，功能有路由分發和過濾。
Config，分佈式配置中心，支持本地倉庫、SVN、Git、Jar 包內配置等模式。
各個組件的職責
每個組件都不是平白無故的產生的，是為了解決某一特定的問題而存在。
Eureka 和 Ribbon，是最基礎的組件，一個註冊服務，一個消費服務。
Hystrix 為了優化 Ribbon、防止整個微服務架構因為某個服務節點的問題導致崩潰，是個保險絲的作用。
Dashboard 給 Hystrix 統計和展示用的，而且監控服務節點的整體壓力和健康情況。
Turbine 是集群收集器，服務於 Dashboard 的。
Feign 是方便我們程序員寫更優美的代碼的。
Zuul 是加在整個微服務最前沿的防火牆和代理器，隱藏微服務結點 IP 端口信息，加強安全保護的。
Config 是為了解決所有微服務各自維護各自的配置，設置一個統一的配置中心，方便修改配置的。
Bus 是因為 config 修改完配置後各個節點都要 refresh 才能生效實在太麻煩，所以交給 bus來通知服務節點刷新配置的。
Stream 是為了簡化研發人員對 MQ 使用的複雜度，弱化 MQ 的差異性，達到程序和 MQ 松耦合。
Sleuth 是因為單次請求在微服務節點中跳轉無法追溯，解決任務鏈日誌追蹤問題的。
spring cloud alibaba
官方宣佈：spring.io/blog/2018/10/
alibaba 的 spring cloud 生態中，提供了微服務開發中必須要用到的組件，就像 Spring Cloud一樣，通過這些組件以及簡化的編程模型使得開發者對於微服務架構的開發變得更簡單。
目前 Spring Cloud Alibaba 這個生態中，已經有相對成熟的體系
- Dubbo， 用於實現高性能 Java RPC 通信
- Nacos， 服務註冊發現、配置管理、服務管理
- Sentinel， 流量控制、熔斷降級、系統負載保護
- RocketMQ， 分佈式消息系統，提供低延時的、高可靠的消息發佈與訂閱服務
- Seata， 高性能微服務分佈式事務解決方案
- 【商業】Alibaba Cloud OSS 阿里雲對象存儲服務（Object Storage Service，簡稱 OSS），是阿里雲提供的海量、安全、低成本、高可靠的雲存儲服務。您可以在任何應用、任何時間、任何地點存儲和訪問任意類型的數據。
- 【商業】Alibaba Cloud SchedulerX 阿里中間件團隊開發的一款分佈式任務調度產品，支持週期性的任務與固定時間點觸發任務。
- 【商業】Alibaba Cloud SMS 覆蓋全球的短信服務，友好、高效、智能的互聯化通訊能力，幫助企業迅速搭建客戶觸達通道。
從這去年 Dubbo 加入到 apache 進行孵化，以及阿里對於開源這塊的重新重視，我相信 springcloud alibaba 未來應該會成為國內主流的微服務解決方案。主要的猜想根據是阿里的技術架構是經歷過無數次雙十一的考驗，意味著 spring cloud alibaba 有著強大的抗壓能力。
開源地址
github.com/spring-cloud
項目組成部分
項目由兩部分組成，一部分是開源組件，另一部分是雲產品開源組件，它的項目前綴是：spring-cloud-alibaba，它有以下幾個特性。
- 服務發現
- 配置管理
- 安全高可用性
雲產品項目前綴是：spring-cloud-alicloud，它有以下幾個特性。
- 對象存儲服務(OSS)
- 任務調度（SchedulerX）
- 日誌服務（SLS）
下一代微服務（service Mesh）
有沒有小夥伴瞭解過 Service Mesh。
什麼是 Service Mesh?
簡單來說，它可以直接翻譯成服務網格。它是一個基礎設施層，用於處理服務之間的通信，並且負責請求的可靠傳輸。什麼意思呢？
serviceMesh 演進
在第一代網絡計算機系統時代，那個時候的程序員需要完成服務的網絡通信，需要自己寫代碼來處理網絡通信的細節，比如數據包的順序、流量控制。
導致網絡處理邏輯和業務邏輯混合在一起，同時對於開發人員來說要求較高。為了解決這個問題，把網絡層的處理邏輯進行抽象，實現了 TCP/IP 技術。對於用戶而言，並不需要關心底層的網絡通信環節。
到了微服務時代，我們也面臨了類似的問題。業務人員在做微服務開發時需要處理一些列比較基礎的事情，比如服務註冊、服務發現、負載均衡、服務熔斷和重試等。
這些功能對於每一個業務程序員而言，都必須要了解和掌握，而實際上這些和業務功能並沒有太大的關係，它理應是一個基礎組件。
所 以 ， 有 些 公 司 就 開 始 開 發 基 礎 組 件 ， 典 型 的 Netflix OSS 套 件（
eureka/hystrix/feign/ribbon/zuul）。
有了這些組件，開發人員就可以使用很少的代碼來實現這些服務治理的功能。而恰恰因為這個原因，使得 Spring Cloud 的普及非常快，幾乎成了微服務的代名詞。
但是到這一步之後，就完美了嗎？
其實不是， 雖然 spring cloud 這個生態中的各種組件能夠解決微服務開發中的各種問題，但是對於一個業務開發而言，需要掌握這麼多的技術組件，門檻比較高。
同時在落地的過程中任何一個組件出現問題，都需要較長的時間來解決。要完全吃透 Spring Cloud 和 Netflix OSS 的各種套件是很困難的。
SpringCloud 微服務帶來的問題
業務團隊的痛點
- 對於業務開發團隊而言，最強的是技術嗎？一定不是，業務團隊最強的一定是對於業務的理解和熟悉程度。
- 而業務應用的核心價值，就是為了實現業務場景，而不是寫微服務，微服務只是一種實現業務的手段。
- 業務團隊除了關心業務之外，他們所面臨的最大的挑戰在於，如何保證系統的穩定性和可擴展性、如何設計一個安全的 open api。如果對服務進行拆分、如何保證跨庫的數據一致性。以及對於舊系統的改造。
- 於公司層面而言，業務團隊的壓力還來自於時間人力的投入，我們用於被各種 deadline 趕著走。所以作為一個業務程序員，如果在這個 deadline 之前還需要花更多的時間投入在spring cloud 這些工具的學習上，那無疑是雪上加霜。公司對於業務團隊的考核，永遠只看結果！
服務治理功能不齊全
SpringCloud 對於服務治理的功能是不夠強大的，如果需要實現企業級的微服務落地以及服務治理，那麼我們還需要基於 SpringCloud 這套體系上來解決這些問題。
跨語言帶來的問題
微服務有一個很重要的特性，就是不同的微服務可以採用自己最擅長的語言來編寫程序。這種特性在企業中落地的時候又會帶來一些問題。
比如公司內部會開發一些公共的類庫或者框架，也或者會使用第三方的類庫或者框架來實現某些功能。
但是由於公司的微服務用了各種各樣的語言，那意味著這些類庫需要針對不同的語言開發兼容版本。如果是主流語言還好，如果是一些小眾語言，那對於這些基礎組件的開發者而言無疑是晴天霹靂
總結
從這些痛點中可以發現，我們所做的所有非業務類的事情，都是為了保證把請求發送到正確的地方，並且能夠及時獲得正確的結果。那對於對於業務開發人員而言，是否有必要去關心這些呢？
回到最開始我們說的一個例子，在進行計算機網絡通信的時候，開發人員有必要去關心網絡通信的細節嗎？我們在使用 http 協議進行數據傳輸時，關心過底層是使用 TCP 還是 udp？數據是怎麼傳輸的？
既然我們不需要關心這些，那對於微服務架構中的這些問題，業務開發人員為什麼一定要關心服務的通訊呢？
技術棧下沉
那麼對於微服務實施來說，能不能像網絡協議的下沉一樣，增加一個微服務層來完成這個事情呢？這就引出了 service mesh在每個服務中，會有一個 service mesh 實例，客戶端發起一個請求，首先會把請求發送到本地的 service mesh 實例，service mesh 實例中會完成完整的服務之間的調用流程，比如服務發現、負載均衡。最終發送給目標服務。
而這個 service mesh 實例，專業名稱應該為:sidecar , 簡單來說，它是原有的客戶端和服務端之間的一個代理在多個服務的調用中，這種通信方式的表現形式就像一個網格，sidecar 之間的鏈接形成了一個網絡，這個就是 service mesh 的由來。
Service Mesh 為業務開發團隊降低了門檻，提供了穩定的基礎設施，最重要的是，讓業務開發團隊從微服務實現的具體技術細節中解放出來迴歸到業務。
關注小編，後續更多精彩內容奉上
