來源：juejin.im/post/5c0ba2bef265da614d08fefe

下文，你將看到業(yè)界主流微服務框架的核心原理，包括服務發(fā)現(xiàn)，網(wǎng)關，配置中心，監(jiān)控等組件，功能和架構原理的簡單介紹。感謝閱讀！??

Hello，Microservices

什么是微服務

微服務Microservices之父，馬丁.福勒，對微服務大概的概述如下：

就目前而言，對于微服務業(yè)界并沒有一個統(tǒng)一的、標準的定義（While there is no precise definition of this architectural style ) 。但通在其常而言，微服務架構是一種架構模式或者說是一種架構風格，它提倡將單一應用程序劃分成一組小的服務，每個服務運行獨立的自己的進程中，服務之間互相協(xié)調(diào)、互相配合，為用戶提供最終價值。服務之間采用輕量級的通信機制互相溝通（通常是基于 HTTP 的 RESTful API ) 。每個服務都圍繞著具體業(yè)務進行構建，并且能夠被獨立地部署到生產(chǎn)環(huán)境、類生產(chǎn)環(huán)境等。另外，應盡量避免統(tǒng)一的、集中式的服務管理機制，對具體的一個服務而言，應根據(jù)業(yè)務上下文，選擇合適的語言、工具對其進行構建，可以有一個非常輕量級的集中式管理來協(xié)調(diào)這些服務?？梢允褂貌煌恼Z言來編寫服務，也可以使用不同的數(shù)據(jù)存儲。

根據(jù)馬丁.福勒的描述，我總結了一下幾點：

康威定律

（字差，勿嫌）

小服務

小服務，沒有特定的標準或者規(guī)范，但他在總體規(guī)范上一定是小的。

進程獨立

每一組服務都是獨立運行的，可能我這個服務運行在tomcat容器，而另一個服務運行在jetty上?？梢酝ㄟ^進程方式，不斷的橫向擴展整個服務。

通信

過去的協(xié)議都是很重的，就像ESB，就像SOAP，輕通信，著意味著相比過去更智能更輕量的服務相互調(diào)用，就所謂smart endpoints and dumb pipes，這些endpoint都是解耦的，完成一個業(yè)務通信調(diào)用串起這些micro service就像是linux系統(tǒng)中通過管道串起一系列命令業(yè)務。

過去的業(yè)務，我們通常會考慮各種各樣的依賴關系，考慮系統(tǒng)耦合帶來的問題。微服務，可以讓開發(fā)者更專注于業(yè)務的邏輯開發(fā)。

部署

不止業(yè)務要獨立，部署也要獨立。不過這也意味著，傳統(tǒng)的開發(fā)流程會出現(xiàn)一定程度的改變，開發(fā)的適合也要有一定的運維指責

管理

傳統(tǒng)的企業(yè)級SOA服務往往很大，不易于管理，耦合性高，團隊開發(fā)成本比較大。微服務，可以讓團隊各思其政的選擇技術實現(xiàn)，不同的service可以根據(jù)各自的需要選擇不同的技術棧來實現(xiàn)其業(yè)務邏輯。

微服務的利與弊

為什么用微服務呢？因為好玩？

不是的。下面是我從網(wǎng)絡上找到說的比較全的優(yōu)點：

• 優(yōu)點每個服務足夠內(nèi)聚，足夠小，代碼容易理解這樣能聚焦一個指定的業(yè)務功能或業(yè)務需求
• 開發(fā)簡單、開發(fā)效率提高，一個服務可能就是專一的只干一件事。
• 微服務能夠被小團隊單獨開發(fā)，這個小團隊是 2 到 5 人的開發(fā)人員組成。
• 微服務是松藕合的，是有功能意義的服務，無論是在開發(fā)階段或部署階段都是獨立的。
• 微服務能使用不同的語言開發(fā)。
• 易于和第三方集成，微服務允許容易且靈活的方式集成自動部署，通過持續(xù)集成工具，如Jenkins,Hudson,bamboo。
• 微服務易于被一個開發(fā)人員理解，修改和維護，這樣小團隊能夠更關注自己的工作成果。無需- - 通過合作才能體現(xiàn)價值。微服務允許你利用融合最新技術。
• 微服務只是業(yè)務邏輯的代碼，不會和 HTML,CSS或其他界面組件混合。
• 每個微服務都有自己的存儲能力，可以有自己的數(shù)據(jù)庫。也可以有統(tǒng)一數(shù)據(jù)庫。

總的來說，微服務的優(yōu)勢，就是在于，面對大的系統(tǒng)，可以有效的減少復雜程度，使服務架構的邏輯更清晰明了。

但是這樣也會帶來很多問題，就譬如分布式環(huán)境下的數(shù)據(jù)一致性，測試的復雜性，運維的復雜性。

什么組織適合使用微服務？

微服務帶了種種優(yōu)點，種種弊端，那么什么組織適合使用微服務？

墨菲定律（設計系統(tǒng)）和康威定律（系統(tǒng)劃分）

康威定律，是一個五十多年前就被提出來的微服務概念。在康威的這篇文章中，最有名的一句話就是：

Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations. - Melvin Conway(1967)

中文直譯大概的意思就是：設計系統(tǒng)的組織，其產(chǎn)生的設計等同于組織之內(nèi)、組織之間的溝通結構?？纯聪旅娴膱D片（來源于互聯(lián)網(wǎng)，侵刪），再想想Apple的產(chǎn)品、微軟的產(chǎn)品設計，就能形象生動的理解這句話。

康威定律

感興趣的各位可以研究一下

架構演化

架構是不斷演化出來的，微服務也是這樣，當從各大科技公司，規(guī)模大到一定程度，完全需要演化成更進一步管理的技術架構體系。

康威定律

（字差，勿嫌）

傳統(tǒng)的團隊，都是面向過程化的，產(chǎn)品想完了去找策劃，策劃完了找開發(fā)，接著順著一步一步找。我們做技術都是為了產(chǎn)品的，一旦過程出來了什么問題，回溯尋找問題會非常耗時。

康威定律

（字差，勿嫌）

使用了微服務架構體系，團隊組織方式需要轉(zhuǎn)變成跨職能團隊，即每個團隊都有產(chǎn)品專家，策劃專家，開發(fā)專家，運維專家，他們使用API方式發(fā)布他們的功能，而平臺使用他們的功能發(fā)布產(chǎn)品

DevOps

devops

微服務技術架構體系

下面我分享一下大部分公司都使用的微服務技術架構體系。

康威定律

（圖差，勿嫌）

服務發(fā)現(xiàn)

主流的服務發(fā)現(xiàn)，分為三種

康威定律

第一種，開發(fā)人員開發(fā)了程序以后，會找運維配一個域名，服務的話通過dns就能找到我們對應的服務

缺點是，由于服務沒有負載均衡功能，對負載均衡服務，可能會有相當大的性能問題。

康威定律

第二種，是目前普遍的做法?？梢詤⒖嘉疑掀┛头治龅膠uul網(wǎng)關，每一個服務都通過服務端內(nèi)置的功能注冊到注冊中心，服務消費者不斷輪詢注冊中心發(fā)現(xiàn)對應的服務，使用內(nèi)置負載均衡調(diào)用服務。

缺點是，對多語言環(huán)境不是很好，你需要單獨給消費者的客戶端開發(fā)服務發(fā)現(xiàn)和負載均衡功能。當然了，這個方法通常都是用在spring cloud上的。

康威定律

第三種，是將客戶端和負載均衡放在同一個主機，而不是同一個進程內(nèi)。

這種方法相對第一種第二種方法來說，改善了他們的缺點，但是會極大增加運維成本。

網(wǎng)關

微服務的網(wǎng)關是什么？

我們可以聯(lián)系生活實際想一下。每一個大的公司，都會有一偏屬于自己的建筑區(qū)，而這建筑區(qū)內(nèi)，都有不少的門衛(wèi)。如果有外來人員進入公司，會先和門衛(wèi)打好招呼，才能進去。

將生活實際聯(lián)系到微服務上，就不難理解網(wǎng)關的意思了。

網(wǎng)關有什么用

康威定律

• 反向路由：很多時候，公司不想讓外部人員看到我們公司的內(nèi)部，就需要網(wǎng)關來進行反向路由。即將外部請求轉(zhuǎn)換成內(nèi)部具體服務條用
• 安全認證：網(wǎng)絡中會有很多惡意訪問，譬如爬蟲，譬如黑客攻擊，網(wǎng)關維護安全功能。
• 限流熔斷：參考我學好分布式zookepper的博客，當請求很多服務不堪重負，會讓我們的服務自動關閉，導致不能用服務。限流熔斷可以有效的避免這類問題
• 日志監(jiān)控：所有的外面的請求都會經(jīng)過網(wǎng)關，這樣我們就可以使用網(wǎng)關來記錄日志信息
• 灰度發(fā)布，藍綠部署。是指能夠平滑過渡的一種發(fā)布方式。在其上可以進行A/B testing，即讓一部分用戶繼續(xù)用產(chǎn)品特性A，一部分用戶開始用產(chǎn)品特性B，如果用戶對B沒有什么反對意見，那么逐步擴大范圍，把所有用戶都遷移到B上面來。

開源網(wǎng)關Zuul架構

zuul架構

zuul網(wǎng)關核心其實是一個servlet，所有請求都會經(jīng)過zuul servlet傳到zuulFilter Runner，然后分發(fā)到三種過濾器。

先說說架構圖左半部分，分別是使用Groovy實現(xiàn)的前置路由過濾器，路由過濾器，后置路由過濾器。

一般請求都會先經(jīng)過前置路由過濾器 處理，一般的自定義java封裝邏輯也會在這里實現(xiàn)。

路由過濾器 ，實現(xiàn)的是找到對應的微服務進行調(diào)用。

調(diào)用完了，響應回來，會經(jīng)過后置路由過濾器 ，通過后置路由過濾器我們可以封裝日志審計的處理。

可以說zuul網(wǎng)關最大的特色就是它三層過濾器。

架構圖右半部分，是zuul網(wǎng)關設計的自定義過濾器加載機制。網(wǎng)關內(nèi)部會有生產(chǎn)者消費者模型，自動的將過濾器腳本發(fā)布到zuul網(wǎng)關讀取加載運行。

配置中心

以前，開發(fā)人員把配置文件放在開發(fā)文件里面，這樣會有很多隱患。譬如，配置規(guī)范不同，無法追溯配置人員。一旦需要大規(guī)模改動配置，改動時間會很長，無法追溯配置人員，從而影響整個產(chǎn)品，后果是我們承擔不起的。

因此就有配置中心這個嘍~

現(xiàn)在的開源中心有百度配置中心 Disconf，spring cloud config，Apollo，今天重點說說現(xiàn)在應用質(zhì)量不錯的配置中心阿波羅。

攜程開源的Apollo

開源地址??：https://github.com/ctripcorp/apollo

康威定律

apollo的配置中心規(guī)模比較大，本地應用會有響應的配置中心客戶端，可以定時同步配置中心里的配置。如果配置中心怠機，會使用緩存來進行配置。

通訊方式

關于通訊方式，一般市面也就是兩種遠程調(diào)用方式，我整理了一個表格：

監(jiān)控預警

監(jiān)控預警對于微服務很重要，一個可靠的監(jiān)控預警體系對微服務運行至關重要。一般監(jiān)控分為如下層次：

康威定律

從基礎設施到用戶端，層層有監(jiān)控，全方位，多角度，每一個層面都很重要?？傮w來說，微服務可分5個監(jiān)控點：日志監(jiān)控 ，Metrics監(jiān)控 ，健康檢查 ，調(diào)用鏈檢查 ，告警系統(tǒng)

監(jiān)控架構

下面的圖是大部分公司的一種監(jiān)控架構圖。每一個服務都有一個agent，agent收集到關鍵信息，會傳到一些MQ中，為了解耦。同時將日志傳入ELK，將Metrics傳入InfluxDB時間序列庫。而像nagios，可以定期向agent發(fā)起信息檢查微服務。

康威定律

調(diào)用鏈監(jiān)控APM

很多公司都有調(diào)用鏈監(jiān)控，就譬如阿里有鷹眼監(jiān)控，點評的Cat，大部分調(diào)用鏈監(jiān)控（沒錯，我指的Zipkin）架構是這樣的??

康威定律

當請求進入Web容器的時候，會經(jīng)過創(chuàng)建Tracer，連接spans（模擬潛在的分布式工作的延遲，該模塊還包含在系統(tǒng)網(wǎng)絡間傳遞跟蹤上下文信息的工具包，如通過http headers）。Spans有一個上下文，其中包含tracer標識符，將其放在表示分布式操作的樹的正確位置。當我們把圖中的各種span放到后端的時候，我們的服務調(diào)用鏈會動態(tài)的生成調(diào)用鏈。

下面是一些市場上用的比較多的調(diào)用鏈監(jiān)控：

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的機制來做字節(jié)碼代碼植入，實現(xiàn)加入traceid和抓取性能數(shù)據(jù)的目的。NewRelic、Oneapm之類的工具在java平臺上的性能分析也是類似的機制。

2、SkyWalking github地址：wu-sheng/sky-walking 這是國內(nèi)一位叫吳晟的兄弟開源的，也是一個對JAVA分布式應用程序集群的業(yè)務運行情況進行追蹤、告警和分析的系統(tǒng)，在github上也有400多顆星了。功能相對pinpoint還是稍弱一些，插件還沒那么豐富，不過也很難得了。

3、Zipkin 官網(wǎng)：OpenZipkin · A distributed tracing system github地址：GitHub - openzipkin/zipkin: Zipkin is a distributed tracing system 這個是twitter開源出來的，也是參考Dapper的體系來做的。

Zipkin的java應用端是通過一個叫Brave的組件來實現(xiàn)對應用內(nèi)部的性能分析數(shù)據(jù)采集。Brave的github地址：github.com/openzipkin/… 這個組件通過實現(xiàn)一系列的java攔截器，來做到對http/servlet請求、數(shù)據(jù)庫訪問的調(diào)用過程跟蹤。然后通過在spring之類的配置文件里加入這些攔截器，完成對java應用的性能數(shù)據(jù)采集。

4、CAT github地址：GitHub - dianping/cat: Central Application Tracking 這個是大眾點評開源出來的，實現(xiàn)的功能也還是蠻豐富的，國內(nèi)也有一些公司在用了。不過他實現(xiàn)跟蹤的手段，是要在代碼里硬編碼寫一些“埋點”，也就是侵入式的。這樣做有利有弊，好處是可以在自己需要的地方加埋點，比較有針對性；壞處是必須改動現(xiàn)有系統(tǒng)，很多開發(fā)團隊不愿意。

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不熟，不過網(wǎng)上介紹這兩個工具的資料還是蠻多的。

康威定律

熔斷、隔離、限流、降級

面對巨大的突發(fā)流量下，大型公司一般會采用一系列的熔斷 （系統(tǒng)自動將服務關閉防止讓出現(xiàn)的問題最大化）、隔離 （將服務和服務隔離，防止一個服務掛了其他服務不能訪問）、限流 （單位時間內(nèi)之允許一定數(shù)量用戶訪問）、降級 （當整個微服務架構整體的負載超出了預設的上限閾值或即將到來的流量預計將會超過預設的閾值時，為了保證重要或基本的服務能正常運行，我們可以將一些 不重要或 不緊急 的服務或任務進行服務的 延遲使用 或 暫停使用）措施。

下面介紹一下hystrix的運行流程（沒找到架構圖不好意思）：

hystrix

每一個微服務調(diào)用時，都會使用hystrix的command方式（上圖的左上角那個），然后使用command同步的，或者是響應式的，或者是異步的，判斷電路是否熔斷（順著圖從左往右看），

如果斷路則走降級fallback；

如果這個線閉合著，但是線程資源沒了，隊列滿了，則走限流措施（看圖的第5步）；

如果走完了，執(zhí)行成功了，則走run()方法，獲取response，但是這個過程如果出錯了，則繼續(xù)走降級fallback.

同時，看圖最上面有一個后綴是health的，這是一個計算整個鏈路是否健康的組件，每一步操作都被它記錄著。

容器與服務編排引擎

從物理機到虛擬機，從虛擬機到容器；從物理集群到open stack，open stack到kubernetes；科技不斷的變化，我們的認知也沒刷新。

我們從容器開始說起，它首先是一個相對獨立的運行環(huán)境，在這一點有點類似于虛擬機，但是不像虛擬機那樣徹底。?虛擬機會將虛擬硬件、內(nèi)核（即操作系統(tǒng)）以及用戶空間打包在新虛擬機當中，虛擬機能夠利用“虛擬機管理程序”運行在物理設備之上。虛擬機依賴于hypervisor，其通常被安裝在“裸金屬”系統(tǒng)硬件之上，這導致hypervisor在某些方面被認為是一種操作系統(tǒng)。一旦 hypervisor安裝完成， 就可以從系統(tǒng)可用計算資源當中分配虛擬機實例了，每臺虛擬機都能夠獲得唯一的操作系統(tǒng)和負載(應用程序)。簡言之，虛擬機先需要虛擬一個物理環(huán)境，然后構建一個完整的操作系統(tǒng)，再搭建一層Runtime，然后供應用程序運行。? ? 對于容器環(huán)境來說，不需要安裝主機操作系統(tǒng)，直接將容器層(比如LXC或libcontainer)安裝在主機操作系統(tǒng)(通常是Linux變種)之上。在安裝完容器層之后，就可以從系統(tǒng)可用計算資源當中分配容器實例了，并且企業(yè)應用可以被部署在容器當中。但是，每個容器化應用都會共享相同的操作系統(tǒng)(單個主機操作系統(tǒng))。容器可以看成一個裝好了一組特定應用的虛擬機，它直接利用了宿主機的內(nèi)核，抽象層比虛擬機更少，更加輕量化，啟動速度極快。

相比于虛擬機，容器擁有更高的資源使用效率，因為它并不需要為每個應用分配單獨的操作系統(tǒng)——實例規(guī)模更小、創(chuàng)建和遷移速度也更快。這意味相比于虛擬機，單個操作系統(tǒng)能夠承載更多的容器。云提供商十分熱衷于容器技術，因為在相同的硬件設備當中，可以部署數(shù)量更多的容器實例。此外，容器易于遷移，但是只能被遷移到具有兼容操作系統(tǒng)內(nèi)核的其他服務器當中，這樣就會給遷移選擇帶來限制。因為容器不像虛擬機那樣同樣對內(nèi)核或者虛擬硬件進行打包，所以每套容器都擁有自己的隔離化用戶空間，從而使得多套容器能夠運行在同一主機系統(tǒng)之上。我們可以看到全部操作系統(tǒng)層級的架構都可實現(xiàn)跨容器共享，惟一需要獨立構建的就是二進制文件與庫。正因為如此，容器才擁有極為出色的輕量化特性。

我們最常用的容器是daocker，網(wǎng)址如下??https://www.docker.com/

容器編排

過去虛擬機可以通過云平臺open stack管理虛擬化，容器時代如何管理容器呢？這就要看看容器編排引擎了。

Apache mesos

mesos是基于master，slave架構，框架決定如何利用資源，master負責管理機器，slave會定期的將機器情況報告給master，master再將信息給框架。master是高可用的，因為zk，也有l(wèi)eader的存在。下面是架構圖??

1544264985310

kubernetes

kubernetes是最近十分火熱的開源容器編排引擎，具體可以參考kubernetes中文文檔

k8s

Kubernetes設計理念和功能其實就是一個類似Linux的分層架構，先說說每一個Kubernetes節(jié)點內(nèi)部，kubelet管理全局全局pod，而每一個pod承載著一個或多個容器，kube-proxy負責網(wǎng)絡代理和負載均衡 。

Kubernetes節(jié)點外部，則是對應的控制管理服務器，負責統(tǒng)一管理各個節(jié)點調(diào)度分配與運行。

- END -
最近熱文
?  一女程序員被判 9 個月：因薪酬等問題離職，rm -f * 刪庫，癱瘓 6 個小時
?  2021年8月全國程序員薪酬終于出爐了！北京以18904元位居榜首
?  外包干三年，必廢！
?  程序員在深圳買千萬豪宅，被領導知道后，被打2星！