作者：tengshe789
https://juejin.im/post/5c0ba2bef265da614d08fefe
微服務的概念最早在 2012 年提出，在 Martin Fowler 的大力推廣下，微服務在 2014 年后得到了大力發展，今天我們通過一組手繪圖來梳理下微服務的核心架構，
什么是微服務？
微服務 Microservices 之父，馬丁.福勒，對微服務大概的概述如下：
就目前而言，對于微服務業界并沒有一個統一的、標準的定義（While there is no precise definition of this architectural style ) ，
但通常在其而言，微服務架構是一種架構模式或者說是一種架構風格，它提倡將單一應用程式劃分成一組小的服務，每個服務運行獨立的自己的行程中，服務之間互相協調、互相配合，為用戶提供最終價值，
服務之間采用輕量級的通信機制互相溝通（通常是基于 HTTP 的 RESTful API ) ，每個服務都圍繞著具體業務進行構建，并且能夠被獨立地部署到生產環境、類生產環境等，
另外，應盡量避免統一的、集中式的服務管理機制，對具體的一個服務而言，應根據業務背景關系，選擇合適的語言、工具對其進行構建，可以有一個非常輕量級的集中式管理來協調這些服務，可以使用不同的語言來撰寫服務，也可以使用不同的資料存盤，
根據馬丁.福勒的描述，我總結了以下幾點：
①小服務
小服務，沒有特定的標準或者規范，但他在總體規范上一定是小的，
②行程獨立
每一組服務都是獨立運行的，可能我這個服務運行在 Tomcat 容器，而另一個服務運行在 Jetty 上，可以通過行程方式，不斷的橫向擴展整個服務，
③通信
過去的協議都是很重的，就像 ESB，就像 SOAP，輕通信，這意味著相比過去更智能更輕量的服務相互呼叫，就所謂 smart endpoints and dumb pipes，
這些 Endpoint 都是解耦的，完成一個業務通信呼叫串起這些 Micro Service 就像是 Linux 系統中通過管道串起一系列命令業務，
過去的業務，我們通常會考慮各種各樣的依賴關系，考慮系統耦合帶來的問題，微服務，可以讓開發者更專注于業務的邏輯開發，
④部署
不止業務要獨立，部署也要獨立，不過這也意味著，傳統的開發流程會出現一定程度的改變，開發的適合也要有一定的運維職責，
⑤管理
傳統的企業級 SOA 服務往往很大，不易于管理，耦合性高，團隊開發成本比較大，
微服務，可以讓團隊各思其政的選擇技術實作，不同的 Service 可以根據各自的需要選擇不同的技術堆疊來實作其業務邏輯，
微服務的利與弊
為什么用微服務呢？因為好玩？不是的，下面是我從網路上找到說的比較全的優點：
-
優點是每個服務足夠內聚，足夠小，代碼容易理解這樣能聚焦一個指定的業務功能或業務需求，
-
開發簡單、開發效率提高，一個服務可能就是專一的只干一件事，
-
微服務能夠被小團隊單獨開發，這個小團隊是 2 到 5 人的開發人員組成，
-
微服務是松耦合的，是有功能意義的服務，無論是在開發階段或部署階段都是獨立的，
-
微服務能使用不同的語言開發，
-
易于和第三方集成，微服務允許容易且靈活的方式集成自動部署，通過持續集成工具，如 Jenkins，Hudson，bamboo，
-
微服務易于被一個開發人員理解，修改和維護，這樣小團隊能夠更關注自己的作業成果，無需通過合作才能體現價值，微服務允許你利用融合最新技術，
-
微服務只是業務邏輯的代碼，不會和 HTML，CSS 或其他界面組件混合，
-
每個微服務都有自己的存盤能力，可以有自己的資料庫，也可以有統一資料庫，
總的來說，微服務的優勢，就是在于，面對大的系統，可以有效的減少復雜程度，使服務架構的邏輯更清晰明了，
但是這樣也會帶來很多問題，就譬如分布式環境下的資料一致性，測驗的復雜性，運維的復雜性，我們公司用了6 年的分布式鎖，很是厲害，推薦大家看下，
什么組織適合使用微服務？
微服務帶了種種優點，種種弊端，那么什么組織適合使用微服務？
①墨菲定律（設計系統）和康威定律（系統劃分）
康威定律，是一個五十多年前就被提出來的微服務概念，在康威的這篇文章中，最有名的一句話就是：
Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations.
-Melvin Conway(1967)
中文直譯大概的意思就是：設計系統的組織，其產生的設計等同于組織之內、組織之間的溝通結構，
看看下面的圖片，再想想 Apple 的產品、微軟的產品設計，就能形象生動的理解這句話，
感興趣的各位可以研究一下！
②架構演化
架構是不斷演化出來的，微服務也是這樣，當從各大科技公司，規模大到一定程度，完全需要演化成更進一步管理的技術架構體系，淘寶千萬并發，14 次架構演進，推薦大家看下，
傳統的團隊，都是面向程序化的，產品想完了去找策劃，策劃完了找開發，接著順著一步一步找，
我們做技術都是為了產品的，一旦程序出來了什么問題，回溯尋找問題會非常耗時，
使用了微服務架構體系，團隊組織方式需要轉變成跨職能團隊，即每個團隊都有產品專家，策劃專家，開發專家，運維專家，他們使用 API 方式發布他們的功能，而平臺使用他們的功能發布產品，推薦一款介面 API 設計神器！推薦使用，
微服務技術架構體系
下面我分享一下大部分公司都使用的微服務技術架構體系：
服務發現
主流的服務發現，分為三種：
第一種，開發人員開發了程式以后，會找運維配一個域名，服務的話通過 DNS 就能找到我們對應的服務，
缺點是，由于服務沒有負載均衡功能，對負載均衡服務，可能會有相當大的性能問題，
第二種，是目前普遍的做法，可以參考 Zuul 網關，每一個服務都通過服務端內置的功能注冊到注冊中心，服務消費者不斷輪詢注冊中心發現對應的服務，使用內置負載均衡呼叫服務，為什么微服務一定要有網關？推薦大家看下，
缺點是，對多語言環境不是很好，你需要單獨給消費者的客戶端開發服務發現和負載均衡功能，當然了，這個方法通常都是用在 Spring Cloud 上的，
第三種，是將客戶端和負載均衡放在同一個主機，而不是同一個行程內，
- [ ] 這種方法相對第一種第二種方法來說，改善了他們的缺點，但是會極大增加運維成本，
網關
微服務的網關是什么？我們可以聯系生活實際想一下，每一個大的公司，都會有一偏屬于自己的建筑區，而這建筑區內，都有不少的門衛，如果有外來人員進入公司，會先和門衛打好招呼，才能進去，
將生活實際聯系到微服務上，就不難理解網關的意思了：
網關的作用如下：
-
反向路由：很多時候，公司不想讓外部人員看到我們公司的內部，就需要網關來進行反向路由，即將外部請求轉換成內部具體服務呼叫，
-
安全認證：網路中會有很多惡意訪問，譬如爬蟲，譬如黑客攻擊，網關維護安全功能，
-
限流熔斷：當請求很多服務不堪重負，會讓我們的服務自動關閉，導致不能用服務，限流熔斷可以有效的避免這類問題，
-
日志監控：所有的外面的請求都會經過網關，這樣我們就可以使用網關來記錄日志資訊，
-
灰度發布，藍綠部署，是指能夠平滑過渡的一種發布方式，在其上可以進行 A/B testing，即讓一部分用戶繼續用產品特性 A，一部分用戶開始用產品特性 B，如果用戶對 B 沒有什么反對意見，那么逐步擴大范圍，把所有用戶都遷移到 B 上面來，
開源網關 Zuul 架構：
Zuul 網關核心其實是一個 Servlet，所有請求都會經過 Zuul Servlet 傳到 ZuulFilter Runner，然后分發到三種過濾器，
先說說架構圖左半部分，分別是使用 Groovy 實作的前置路由過濾器，路由過濾器，后置路由過濾器，
一般請求都會先經過前置路由過濾器處理，一般的自定義 Java 封裝邏輯也會在這里實作，
路由過濾器，實作的是找到對應的微服務進行呼叫，呼叫完了，回應回來，會經過后置路由過濾器，通過后置路由過濾器我們可以封裝日志審計的處理，
可以說 Zuul 網關最大的特色就是它的三層過濾器，是 Zuul 網關設計的自定義過濾器加載機制，
網關內部會有生產者消費者模型，自動的將過濾器腳本發布到 Zuul 網關讀取加載運行，
配置中心
以前，開發人員把組態檔放在開發檔案里面，這樣會有很多隱患，譬如，配置規范不同，無法追溯配置人員，微服務配置中心全面對比，哪個更牛逼？這篇推薦大家看下，
一旦需要大規模改動配置，改動時間會很長，無法追溯配置人員，從而影響整個產品，后果是我們承擔不起的，
因此就有配置中心這個嘍！現在的開源中心有百度配置中心 Disconf，Spring Cloud Config，Apollo，
今天重點說說現在應用質量不錯的配置中心，攜程開源的阿波羅（Apollo）：
Apollo 的配置中心規模比較大，本地應用會有回應的配置中心客戶端，可以定時同步配置中心里的配置，如果配置中心怠機，會使用快取來進行配置，關注微信公眾號：Java技術堆疊，在后臺回復：架構，可以獲取我整理的 N 篇最新架構干貨，
通訊方式
關于通訊方式，一般市面也就是兩種遠程呼叫方式，我整理了一個表格：
監控預警
監控預警對于微服務很重要，一個可靠的監控預警體系對微服務運行至關重要，
一般監控分為如下層次：
從基礎設施到用戶端，層層有監控，全方位，多角度，每一個層面都很重要，
總體來說，微服務可分為 5 個監控點：
-
日志監控
-
Metrics 監控
-
健康檢查
-
呼叫鏈檢查
-
告警系統
①監控架構
下面的圖是大部分公司的一種監控架構圖，每一個服務都有一個 Agent，Agent 收集到關鍵資訊，會傳到一些 MQ 中，為了解耦，
同時將日志傳入 ELK，將 Metrics 傳入 InfluxDB 時間序列庫，而像 Nagios，可以定期向 Agent 發起資訊檢查微服務，關注微信公眾號：Java技術堆疊，在后臺回復：架構，可以獲取我整理的 N 篇最新架構干貨，
②呼叫鏈監控 APM
很多公司都有呼叫鏈監控，就譬如阿里有鷹眼監控，點評的 Cat，大部分呼叫鏈監控（沒錯，我指的 Zipkin）架構是這樣的：
當請求進入 Web 容器的時候，會經過創建 Tracer，連接 Spans（模擬潛在的分布式作業的延遲，該模塊還包含在系統網路間傳遞跟蹤背景關系資訊的工具包，如通過 HTTP Headers），
Spans 有一個背景關系，其中包含 Tracer 識別符號，將其放在表示分布式操作的樹的正確位置，
當我們把圖中的各種 Span 放到后端的時候，我們的服務呼叫鏈會動態的生成呼叫鏈，
下面是一些市場上用的比較多的呼叫鏈監控對比：
熔斷、隔離、限流、降級
面對巨大的突發流量下，大型公司一般會采用一系列的熔斷（系統自動將服務關閉防止讓出現的問題最大化）、隔離（將服務和服務隔離，防止一個服務掛了其他服務不能訪問）、限流（單位時間內之允許一定數量用戶訪問）、降級（當整個微服務架構整體的負載超出了預設的上限閾值或即將到來的流量預計將會超過預設的閾值時，為了保證重要或基本的服務能正常運行，我們可以將一些不重要或不緊急的服務或任務進行服務的延遲使用或暫停使用）措施，
下面介紹一下 Hystrix 的運行流程：
Hystrix 停止開發，Spring Cloud 何去何從？
每一個微服務呼叫時，都會使用 Hystrix 的 Command 方式（上圖的左上角那個），然后使用 Command 同步的，或者是回應式的，或者是異步的，判斷電路是否熔斷（順著圖從左往右看），如果斷路則走降級 Fallback，
如果這個線閉合著，但是執行緒資源沒了，佇列滿了，則走限流措施（看圖的第 5 步），
如果走完了，執行成功了，則走 run() 方法，獲取 Response，但是這個程序如果出錯了，則繼續走降級 Fallback，
同時，看圖最上面有一個后綴是 Health 的，這是一個計算整個鏈路是否健康的組件，每一步操作都被它記錄著，
容器與服務編排引擎
從物理機到虛擬機，從虛擬機到容器；從物理集群到 OpenStack，OpenStack 到 Kubernetes；科技不斷的變化，我們的認知也沒重繪，
我們從容器開始說起，它首先是一個相對獨立的運行環境，在這一點有點類似于虛擬機，但是不像虛擬機那樣徹底，
虛擬機會將虛擬硬體、內核（即作業系統）以及用戶空間打包在新虛擬機當中，虛擬機能夠利用“虛擬機管理程式”運行在物理設備之上，
虛擬機依賴于 Hypervisor，其通常被安裝在“裸金屬”系統硬體之上，這導致 Hypervisor 在某些方面被認為是一種作業系統，
一旦 Hypervisor 安裝完成， 就可以從系統可用計算資源當中分配虛擬機實體了，每臺虛擬機都能夠獲得唯一的作業系統和負載（應用程式），
簡言之，虛擬機先需要虛擬一個物理環境，然后構建一個完整的作業系統，再搭建一層 Runtime，然后供應用程式運行，
對于容器環境來說，不需要安裝主機作業系統，直接將容器層（比如 LXC 或 Libcontainer）安裝在主機作業系統（通常是 Linux 變種）之上，
在安裝完容器層之后，就可以從系統可用計算資源當中分配容器實體了，并且企業應用可以被部署在容器當中，
但是，每個容器化應用都會共享相同的作業系統(單個主機作業系統)，容器可以看成一個裝好了一組特定應用的虛擬機，它直接利用了宿主機的內核，抽象層比虛擬機更少，更加輕量化，啟動速度極快，
相比于虛擬機，容器擁有更高的資源使用效率，因為它并不需要為每個應用分配單獨的作業系統——實體規模更小、創建和遷移速度也更快，這意味著相比于虛擬機，單個作業系統能夠承載更多的容器，
云提供商十分熱衷于容器技術，因為在相同的硬體設備當中，可以部署數量更多的容器實體，
此外，容器易于遷移，但是只能被遷移到具有兼容作業系統內核的其他服務器當中，這樣就會給遷移選擇帶來限制，
因為容器不像虛擬機那樣同樣對內核或者虛擬硬體進行打包，所以每套容器都擁有自己的隔離化用戶空間，從而使得多套容器能夠運行在同一主機系統之上，
我們可以看到全部作業系統層級的架構都可實作跨容器共享，惟一需要獨立構建的就是二進制檔案與庫，
正因為如此，容器才擁有極為出色的輕量化特性，我們最常用的容器是 Docker，
①容器編排
過去虛擬機可以通過云平臺 OpenStack 管理虛擬化，容器時代如何管理容器呢？這就要看看容器編排引擎了，
Apache Mesos：Mesos 是基于 Master，Slave 架構，框架決定如何利用資源，Master 負責管理機器，Slave 會定期的將機器情況報告給 Master，Master 再將資訊給框架，Master 是高可用的，因為 ZK，也有 Leader 的存在，
下面是架構圖：
Kubernetes：Kubernetes 是最近十分火熱的開源容器編排引擎，具體可以參考前幾天分享的一篇文章《我花了10個小時，寫出了這篇K8S架構決議》：
Kubernetes 設計理念和功能其實就是一個類似 Linux 的分層架構，先說說每一個 Kubernetes 節點內部，kubelet 管理全域全域 pod，而每一個 pod 承載著一個或多個容器，kube-proxy 負責網路代理和負載均衡，
Kubernetes 節點外部，則是對應的控制管理服務器，負責統一管理各個節點調度分配與運行，
②服務網格化
關于服務網路化，后面會更加深入的為大家進行講解，
資料與文獻：
馬丁.福勒對微服務的描述
微服務架構的理論基礎 - 康威定律
呼叫鏈選型之Zipkin，Pinpoint，SkyWalking，CAT
近期熱文推薦：
1.Java 15 正式發布， 14 個新特性，重繪你的認知！！
2.終于靠開源專案弄到 IntelliJ IDEA 激活碼了，真香！
3.我用 Java 8 寫了一段邏輯，同事直呼看不懂，你試試看，，
4.吊打 Tomcat ，Undertow 性能很炸！！
5.《Java開發手冊（嵩山版）》最新發布，速速下載！
覺得不錯，別忘了隨手點贊+轉發哦！
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/241702.html
標籤：Java
上一篇：110_注解和反射