在公司學習了接近一個月。
一個月內，從0開始開始接觸分散式微服務架構，給了我不小的收穫。今天，我來從頭到尾梳理一下，有關微服務架構的核心內容（全是乾貨）。
下文，你將看到業界主流微服務框架的核心原理，包括服務發現，閘道器，配置中心，監控等元件，功能和架構原理的簡單介紹。感謝閱讀！?
想要解鎖更多新姿勢？請訪問我的部落格。?
Hello，Microservices
什麼是微服務
微服務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或其他介面元件混合。
每個微服務都有自己的儲存能力，可以有自己的資料庫。也可以有統一資料庫。
總的來說，微服務的優勢，就是在於，面對大的系統，可以有效的減少複雜程度，使服務架構的邏輯更清晰明瞭。
但是這樣也會帶來很多問題，就譬如分散式環境下的資料一致性，測試的複雜性，運維的複雜性。
什麼組織適合使用微服務？
微服務帶了種種優點，種種弊端，那麼什麼組織適合使用微服務？
墨菲定律（設計系統）和康威定律（系統劃分）
康威定律，是一個五十多年前就被提出來的微服務概念。在康威的這篇文章中，最有名的一句話就是：
Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations. - Melvin Conway(1967)
中文直譯大概的意思就是：設計系統的組織，其產生的設計等同於組織之內、組織之間的溝通結構。看看下面的圖片（來源於網際網路，侵刪），再想想Apple的產品、微軟的產品設計，就能形象生動的理解這句話。
感興趣的各位可以研究一下
架構演化
架構是不斷演化出來的，微服務也是這樣，當從各大科技公司，規模大到一定程度，完全需要演化成更進一步管理的技術架構體系。
（字差，勿嫌）
傳統的團隊，都是程式導向化的，產品想完了去找策劃，策劃完了找開發，接著順著一步一步找。我們做技術都是為了產品的，一旦過程出來了什麼問題，回溯尋找問題會非常耗時。
（字差，勿嫌）
使用了微服務架構體系，團隊組織方式需要轉變成跨職能團隊，即每個團隊都有產品專家，策劃專家，開發專家，運維專家，他們使用API方式釋出他們的功能，而平臺使用他們的功能釋出產品
微服務技術架構體系
下面我分享一下大部分公司都使用的微服務技術架構體系。
（圖差，勿嫌）
服務發現
主流的服務發現，分為三種
第一種，開發人員開發了程式以後，會找運維配一個域名，服務的話通過dns就能找到我們對應的服務
缺點是，由於服務沒有負載均衡功能，對負載均衡服務，可能會有相當大的效能問題。
第二種，是目前普遍的做法。可以參考我上篇部落格分析的zuul閘道器，每一個服務都通過服務端內建的功能註冊到註冊中心，服務消費者不斷輪詢註冊中心發現對應的服務，使用內建負載均衡呼叫服務。
缺點是，對多語言環境不是很好，你需要單獨給消費者的客戶端開發服務發現和負載均衡功能。當然了，這個方法通常都是用在spring cloud上的。
第三種，是將客戶端和負載均衡放在同一個主機，而不是同一個程式內。
這種方法相對第一種第二種方法來說，改善了他們的缺點，但是會極大增加運維成本。
閘道器
微服務的閘道器是什麼？
我們可以聯絡生活實際想一下。每一個大的公司，都會有一偏屬於自己的建築區，而這建築區內，都有不少的門衛。如果有外來人員進入公司，會先和門衛打好招呼，才能進去。
將生活實際聯絡到微服務上，就不難理解閘道器的意思了。
閘道器有什麼用
- 反向路由：很多時候，公司不想讓外部人員看到我們公司的內部，就需要閘道器來進行反向路由。即將外部請求轉換成內部具體服務條用
- 安全認證：網路中會有很多惡意訪問，譬如爬蟲，譬如黑客攻擊，閘道器維護安全功能。
- 限流熔斷：參考我學好分散式zookepper的部落格，當請求很多服務不堪重負，會讓我們的服務自動關閉，導致不能用服務。限流熔斷可以有效的避免這類問題
- 日誌監控：所有的外面的請求都會經過閘道器，這樣我們就可以使用閘道器來記錄日誌資訊
- 灰度釋出，藍綠部署。是指能夠平滑過渡的一種釋出方式。在其上可以進行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
開源地址?：github.com/ctripcorp/a…
apollo的配置中心規模比較大，本地應用會有響應的配置中心客戶端，可以定時同步配置中心裡的配置。如果配置中心怠機，會使用快取來進行配置。
通訊方式
關於通訊方式，一般市面也就是兩種遠端呼叫方式，我整理了一個表格：
| RPC | REST | |
|---|---|---|
| 耦合性 | 強耦合 | 鬆散耦合 |
| 訊息協議 | TCP | HTTP |
| 通訊協議 | 二進位制 | 文字XML，Json |
| 效能 | 高 | 低於RPC |
| 介面契約IDL | thrift,protobuf,IdL | Swagger |
| 客戶端 | 強型別客戶端，一般自動生成 | 一般HTTP可訪問，生成強型別客戶端，多語言支援好 |
| 案例 | Dubbo，Dubbox,motan,tars,grpc,thrift | spring boot,tax-rs,dropwizard |
| 開發者友好 | 客戶端比較方面，二進位制訊息不能讀 | 可讀訊息 |
| 對外開放 | 一般需要轉成REST/文字協議 | 可直接對外開發 |
監控預警
監控預警對於微服務很重要，一個可靠的監控預警體系對微服務執行至關重要。一般監控分為如下層次：
從基礎設施到使用者端，層層有監控，全方位，多角度，每一個層面都很重要。總體來說，微服務可分5個監控點：日誌監控，Metrics監控，健康檢查，呼叫鏈檢查，告警系統
監控架構
下面的圖是大部分公司的一種監控架構圖。每一個服務都有一個agent，agent收集到關鍵資訊，會傳到一些MQ中，為了解耦。同時將日誌傳入ELK，將Metrics傳入InfluxDB時間序列庫。而像nagios，可以定期向agent發起資訊檢查微服務。
呼叫鏈監控APM
很多公司都有呼叫鏈監控，就譬如阿里有鷹眼監控，點評的Cat，大部分呼叫鏈監控（沒錯，我指的Zipkin）架構是這樣的?
當請求進入Web容器的時候，會經過建立Tracer，連線spans（模擬潛在的分散式工作的延遲，該模組還包含在系統網路間傳遞跟蹤上下文資訊的工具包，如通過http headers）。Spans有一個上下文，其中包含tracer識別符號，將其放在表示分散式操作的樹的正確位置。當我們把圖中的各種span放到後端的時候，我們的服務呼叫鏈會動態的生成呼叫鏈。
下面是一些市場上用的比較多的呼叫鏈監控：
1、Pinpoint github地址：GitHub - naver/pinpoint: Pinpoint is an open source APM (Application Performance Management) tool for large-scale distributed systems written in Java. 對java領域的效能分析有興趣的朋友都應該看看這個開源專案，這個是一個韓國團隊開源出來的，通過JavaAgent的機制來做位元組碼程式碼植入，實現加入traceid和抓取效能資料的目的。 NewRelic、Oneapm之類的工具在java平臺上的效能分析也是類似的機制。
2、SkyWalking github地址：wu-sheng/sky-walking 這是國內一位叫吳晟的兄弟開源的，也是一個對JAVA分散式應用程式叢集的業務執行情況進行追蹤、告警和分析的系統，在github上也有400多顆星了。 功能相對pinpoint還是稍弱一些，外掛還沒那麼豐富，不過也很難得了。
3、Zipkin 官網：OpenZipkin · A distributed tracing system github地址：GitHub - openzipkin/zipkin: Zipkin is a distributed tracing system 這個是twitter開源出來的，也是參考Dapper的體系來做的。
Zipkin的java應用端是通過一個叫Brave的元件來實現對應用內部的效能分析資料採集。 Brave的github地址：github.com/openzipkin/… 這個元件通過實現一系列的java攔截器，來做到對http/servlet請求、資料庫訪問的呼叫過程跟蹤。 然後通過在spring之類的配置檔案里加入這些攔截器，完成對java應用的效能資料採集。
4、CAT github地址：GitHub - dianping/cat: Central Application Tracking 這個是大眾點評開源出來的，實現的功能也還是蠻豐富的，國內也有一些公司在用了。 不過他實現跟蹤的手段，是要在程式碼裡硬編碼寫一些“埋點”，也就是侵入式的。 這樣做有利有弊，好處是可以在自己需要的地方加埋點，比較有針對性；壞處是必須改動現有系統，很多開發團隊不願意。
5、Xhprof/Xhgui 這兩個工具的組合，是針對PHP應用提供APM能力的工具，也是非侵入式的。 Xhprof github地址：GitHub - preinheimer/xhprof: XHGUI is a GUI for the XHProf PHP extension, using a database backend, and pretty graphs to make it easy to use and interpret. Xhgui github地址：GitHub - perftools/xhgui: A graphical interface for XHProf data built on MongoDB 我對PHP不熟，不過網上介紹這兩個工具的資料還是蠻多的。
熔斷、隔離、限流、降級
面對巨大的突發流量下，大型公司一般會採用一系列的熔斷（系統自動將服務關閉防止讓出現的問題最大化）、隔離（將服務和服務隔離，防止一個服務掛了其他服務不能訪問）、限流（單位時間內之允許一定數量使用者訪問）、降級（當整個微服務架構整體的負載超出了預設的上限閾值或即將到來的流量預計將會超過預設的閾值時，為了保證重要或基本的服務能正常執行，我們可以將一些 不重要或 不緊急 的服務或任務進行服務的 延遲使用 或 暫停使用）措施。
下面介紹一下hystrix的執行流程（沒找到架構圖不好意思）：
每一個微服務呼叫時，都會使用hystrix的command方式（上圖的左上角那個），然後使用command同步的，或者是響應式的，或者是非同步的，判斷電路是否熔斷（順著圖從左往右看），
如果斷路則走降級fallback；
如果這個線閉合著，但是執行緒資源沒了，佇列滿了，則走限流措施（看圖的第5步）；
如果走完了，執行成功了，則走run()方法，獲取response，但是這個過程如果出錯了，則繼續走降級fallback.
同時，看圖最上面有一個字尾是health的，這是一個計算整個鏈路是否健康的元件，每一步操作都被它記錄著。
容器與服務編排引擎
從物理機到虛擬機器，從虛擬機器到容器；從物理叢集到open stack，open stack到kubernetes；科技不斷的變化，我們的認知也沒重新整理。
我們從容器開始說起，它首先是一個相對獨立的執行環境，在這一點有點類似於虛擬機器，但是不像虛擬機器那樣徹底。 虛擬機器會將虛擬硬體、核心（即作業系統）以及使用者空間打包在新虛擬機器當中，虛擬機器能夠利用“虛擬機器管理程式”執行在物理裝置之上。虛擬機器依賴於hypervisor，其通常被安裝在“裸金屬”系統硬體之上，這導致hypervisor在某些方面被認為是一種作業系統。一旦 hypervisor安裝完成， 就可以從系統可用計算資源當中分配虛擬機器例項了，每臺虛擬機器都能夠獲得唯一的作業系統和負載(應用程式)。簡言之，虛擬機器先需要虛擬一個物理環境，然後構建一個完整的作業系統，再搭建一層Runtime，然後供應用程式執行。 對於容器環境來說，不需要安裝主機作業系統，直接將容器層(比如LXC或libcontainer)安裝在主機作業系統(通常是Linux變種)之上。在安裝完容器層之後，就可以從系統可用計算資源當中分配容器例項了，並且企業應用可以被部署在容器當中。但是，每個容器化應用都會共享相同的作業系統(單個主機作業系統)。容器可以看成一個裝好了一組特定應用的虛擬機器，它直接利用了宿主機的核心，抽象層比虛擬機器更少，更加輕量化，啟動速度極快。
相比於虛擬機器，容器擁有更高的資源使用效率，因為它並不需要為每個應用分配單獨的作業系統——例項規模更小、建立和遷移速度也更快。這意味相比於虛擬機器，單個作業系統能夠承載更多的容器。雲提供商十分熱衷於容器技術，因為在相同的硬體裝置當中，可以部署數量更多的容器例項。此外，容器易於遷移，但是隻能被遷移到具有相容作業系統核心的其他伺服器當中，這樣就會給遷移選擇帶來限制。因為容器不像虛擬機器那樣同樣對核心或者虛擬硬體進行打包，所以每套容器都擁有自己的隔離化使用者空間，從而使得多套容器能夠執行在同一主機系統之上。我們可以看到全部作業系統層級的架構都可實現跨容器共享，惟一需要獨立構建的就是二進位制檔案與庫。正因為如此，容器才擁有極為出色的輕量化特性。
我們最常用的容器是daocker，網址如下?https://www.docker.com/
容器編排
過去虛擬機器可以通過雲平臺open stack管理虛擬化，容器時代如何管理容器呢？這就要看看容器編排引擎了。
Apache mesos
mesos是基於master，slave架構，框架決定如何利用資源，master負責管理機器，slave會定期的將機器情況報告給master，master再將資訊給框架。master是高可用的，因為zk，也有leader的存在。下面是架構圖?
kubernetes
kubernetes是最近十分火熱的開源容器編排引擎，具體可以參考kubernetes中文文件
Kubernetes設計理念和功能其實就是一個類似Linux的分層架構，先說說每一個Kubernetes節點內部，kubelet管理全域性全域性pod，而每一個pod承載著一個或多個容器，kube-proxy負責網路代理和負載均衡 。
Kubernetes節點外部，則是對應的控制管理伺服器，負責統一管理各個節點排程分配與執行。
服務網格化
。。。待更新
資料與文獻
呼叫鏈選型之Zipkin，Pinpoint，SkyWalking，CAT
結束
此片完了~ 想要了解更多精彩新姿勢？
請訪問我的個人部落格
本篇為原創內容，已在個人部落格率先發表，隨後看心情可能會在CSDN，segmentfault，掘金，簡書，開源中國同步發出。如有雷同，緣分呢兄弟。趕快加個好友，我們們兩個想個號碼， 買個彩票，先掙他個幾百萬?