什麼是微服務？
微服務 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 次架構演進 ，推薦大家看下。 傳統的團隊，都是面向過程化的，産品想完了去找策劃，策劃完了找開發，接着順着一步一步找。
我們做技術都是為了産品的，一旦過程出來了什麼問題，回溯尋找問題會非常耗時。
微服務技術架構體系
下面我分享一下大部分公司都使用的微服務技術架構體系：
服務發現
主流的服務發現，分為三種：
第一種，開發人員開發了程式以後，會找運維配一個域名，服務的話通過 DNS 就能找到我們對應的服務。
缺點是，由于服務沒有負載均衡功能，對負載均衡服務，可能會有相當大的性能問題。
第二種，是目前普遍的做法。可以參考 Zuul 網關，每一個服務都通過服務端内置的功能注冊到注冊中心，服務消費者不斷輪詢注冊中心發現對應的服務，使用内置負載均衡調用服務。為什麼微服務一定要有網關？推薦大家看下。
缺點是，對多語言環境不是很好，你需要單獨給消費者的用戶端開發服務發現和負載均衡功能。當然了，這個方法通常都是用在 Spring Cloud 上的。
第三種，是将用戶端和負載均衡放在同一個主機，而不是同一個程序内。
這種方法相對第一種第二種方法來說，改善了他們的缺點，但是會極大增加運維成本。
網關
微服務的網關是什麼？我們可以聯系生活實際想一下。每一個大的公司，都會有一偏屬于自己的建築區，而這建築區内，都有不少的門衛。如果有外來人員進入公司，會先和門衛打好招呼，才能進去。
将生活實際聯系到微服務上，就不難了解網關的意思了：
網關的作用如下：
反向路由：很多時候，公司不想讓外部人員看到我們公司的内部，就需要網關來進行反向路由。即将外部請求轉換成内部具體服務調用。
安全認證：網絡中會有很多惡意通路，譬如爬蟲，譬如黑客攻擊，網關維護安全功能。
限流熔斷：當請求很多服務不堪重負，會讓我們的服務自動關閉，導緻不能用服務。限流熔斷可以有效的避免這類問題。
日志監控：所有的外面的請求都會經過網關，這樣我們就可以使用網關來記錄日志資訊。
灰階釋出，藍綠部署。是指能夠平滑過渡的一種釋出方式。在其上可以進行 A/B testing。即讓一部分使用者繼續用産品特性 A，一部分使用者開始用産品特性 B，如果使用者對 B 沒有什麼反對意見，那麼逐漸擴大範圍，把所有使用者都遷移到 B 上面來。
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