1.什麼是微服務
1）一組小的服務（大小沒有特别的标準，隻要同一團隊的工程師了解服務的辨別一緻即可）
2）獨立的程序（java的tomcat，nodejs等）
3）輕量級的通信（不是soap，是http協定）
4）基于業務能力（類似使用者服務，商品服務等等）
5）獨立部署（疊代速度快）
6）無集中式管理（無須統一技術棧，可以根據不同的服務或者團隊進行靈活選擇）
2. 怎麼權衡微服務的利于弊
利：
- 強子產品邊界 。（子產品化的演化過程：類-->元件/類庫（sdk）-->服務(service)，方式越來越靈活）
- 可獨立部署。
- 技術多樣性。
弊：
- 分布式複雜性。
- 最終一緻性。（各個服務的團隊，資料也是分散式治理，會出現不一緻的問題）
- 運維複雜性。
- 測試複雜性。
3. 企業在什麼時候考慮引入微服務
從生産力和系統的複雜性這兩個方面來看。公司一開始的時候，業務複雜性不高，這時候是驗證商業模式的時候，業務簡單，用單體服務反而生産力很高。随着公司的發展，業務複雜性慢慢提高，這時候就可以采用微服務來提升生産力了。至于這個轉化的點，需要團隊的架構師來進行各方面衡量，就個人經驗而言，團隊發展到百人以上，采用微服務就很有必要了。
有些架構師是具有微服務架構能力，是以設計系統時就直接設計成了微服務，而不是通過單服務慢慢演化發展成微服務。在這裡我并不推薦這種做法，因為一開始對業務領域并不是很了解，并且業務模式還沒有得到驗證，這時候上微服務風險比較高，很有可能失敗。是以建議大家在單服務的應用成熟時，并且對業務領域比較熟悉的時候，如果發現單服務無法适應業務發展時，再考慮微服務的設計和架構。
4.微服務的組織架構
如上圖左邊，傳統的企業中，團隊是按職能劃分的。開發一個項目時，會從不同的職能團隊找人進行開發，開發完成後，再各自回到自己的職能團隊，這種模式實踐證明，效率還是比較低的。
如上圖右邊，圍繞每個業務線或産品，按服務劃分團隊。團隊成員從架構到運維，形成一個完整的閉環。一直圍繞在産品周圍，進行不斷的疊代。不會像傳統的團隊一樣離開。這樣開發效率會比較高。至于這種團隊的規模，建議按照亞馬遜的兩個披薩原則，大概10人左右比較好。
5：怎麼了解中台戰略和微服務
中台戰略的由來：馬雲2015年去歐洲的一家公司supersell參觀，發現這個公司的創新能力非常強，團隊的規模很小，但是開發效率很高。他們就是采用中台戰略。馬雲感觸很深，回國後就在集團内部推出了中台戰略。
簡單的了解就是把傳統的前背景體系中的背景進行了細分。阿裡巴巴提出了大中台小前台的戰略。就是強化業務和技術中台，把前端的應用變得更小更靈活。當中台越強大，能力就越強，越能更好的快速響應前台的業務需求。打個比喻，就是土壤越肥沃，越适合生長不同的生物，打造好的生态系統。
6：服務分層
每個公司的服務分層都不相同，有的公司服務沒有分層，有的怎分層很多。目前業界沒有統一的标準。
下面推薦一個比較容易了解的兩層結構。
1：基礎服務： 比如一個電商網站，商品服務和訂單服務就屬于基礎服務（核心領域服務）。緩存服務，監控服務，消息隊列等也屬于基礎服務（公共服務）
2：聚合服務 ：例如網關服務就算一種聚合服務（适配服務）。
這是一種邏輯劃分，不是實體劃分，實際設計的東西很多很複雜。
7：微服務的技術架構體系
下圖是一個成型的網際網路微服務的架構體系：
1：接入層 負載均衡作用，運維團隊負責
2：網關層 反向路由，安全驗證，限流等
3：業務服務層 基礎服務和領域服務
4：支撐服務層
5：平台服務
6：基礎設施層 運維團隊負責。（或者阿裡雲）
8：微服務的服務發現的三種方式
第一種：如下圖所示，傳統的服務發現（大部分公司的做法）。服務上線後，通知運維，申請域名，配置路由。調用方通過dns域名解析，經過負載均衡路由，進行服務通路。缺點： LB的單點風險，服務穿透LB，性能也不是太好
第二種：也叫用戶端發現方式。如下圖所示。通過服務注冊的方式，服務提供者先注冊服務。消費者通過注冊中心擷取相應服務。
并且把LB的功能移動到了消費者的程序内，消費者根據自身路由去擷取相應服務。優點是，沒有了LB單點問題，也沒有了LB的中間一跳，性能也比較好。但是這種方式有一個非常明顯的缺點就是具有非常強的耦合性。針對不同的語言，每個服務的用戶端都得實作一套服務發現的功能。
第三種：也叫服務端發現方式，如下圖所示。和第二種很相似。但是LB功能獨立程序單獨部署，是以解決了用戶端多語言開發的問題。唯一的缺點就是運維成比較高，每個節點都得部署一個LB的代理，例如nginx。
9.微服務網關
網關就好比一個公司的門衛。屏蔽内部細節，統一對外服務接口。
下圖是一個網關所處位置的示例圖。
10：Netflix Zuul網關介紹
核心就是一個servlet，通過filter機制實作的。主要分為三類過濾器：前置過濾器，過濾器和後置過濾器。
主要特色是，這些過濾器可以動态插拔，就是如果需要增加減少過濾器，可以不用重新開機，直接生效。原理就是：通過一個db維護過濾器（上圖藍色部分），如果增加過濾器，就将新過濾器編譯完成後push到db中，有線程會定期掃描db，發現新的過濾器後，會上傳到網關的相應檔案目錄下，并通知過濾器loader進行加載相應的過濾器。
整個網關調用的流程
上圖從左變http Request開始經過三類過濾器，最終到最右邊的Http Response，這就是Zull網關的整個調用流程。
11：微服務的路由發現體系
整個微服務的路由發現體系，一般由服務注冊中心和網關兩部分組成。以NetFlix為例子，Eureka和Zull這兩個元件支撐了netFlix整個的路由發現體系。如下圖所示，首先外部請求發送到網關，網關去服務注冊中心擷取相應的服務，進行調用。其次内部服務間的調用，也通過服務注冊中心進行的
12.微服務配置中心
目前大部分公司都是把配置寫到配置檔案中，遇到修改配置的情況，成本很高。并且沒有修改配置的記錄，出問題很難追溯。配置中心就接解決了以上的問題。
可配置内容：資料庫連接配接，業務參數等等
配置中心就是一個web服務，配置人員通過背景頁面修改配置，各個服務就會得到新的配置參數。實作方式主要有兩種，一種是push，另一種是pull。兩張方式各有優缺點。push實時性較好，但是遇到網絡抖動，會丢失消息。pull不會丢失消息但是實時性差一些。大家可以同時兩種方式使用，實作一個比較好的效果。如下圖所示，這是一個國内知名網際網路公司的配置中心架構圖。
13：RPC遇到了REST
内部一些核心服務，性能要求比較高的可以采用RPC，對外服務的一般可以采用rest。
14：服務架構和治理
微服務很多的時候，就需要有治理了。一個好的微服務架構一般分為以下14個部分。如下圖所示。這就是開篇所說的，微服務涉及的東西很多，有些初創公司和業務不成熟的産品是不太适合的，成本比較高。
目前國内比較好的微服務架構就是阿裡巴巴的DUBBO了,國外的就是spring cloud，
阿裡P8架構師談：微服務Dubbo和SpringCloud架構設計、優劣勢比較
15：監控體系
監控是微服務治理的重要環節。一般分為以下四層。如下圖所示。
監控的内容分為五個部分：日志監控，Metrics監控（服務調用情況），調用鍊監控，告警系統和健康檢查。
日志監控，國内常用的就是ELK+KAFKA來實作。健康檢查和Metrics，像spring boot會自帶。Nagios也是一個很好的開源監控架構。
16:Trace調用鍊監控
調用鍊監控是用來追蹤微服務之前依賴的路徑和問題定位。例如阿裡的鷹眼系統。主要原理就是子節點會記錄父節點的id資訊。
下圖是目前比較流行的調用鍊監控架構。
17：微服務的限流熔斷
假設服務A依賴服務B和服務C，而B服務和C服務有可能繼續依賴其他的服務，繼續下去會使得調用鍊路過長。如果在A的鍊路上某個或幾個被調用的子服務不可用或延遲較高，則會導緻調用A服務的請求被堵住，堵住的請求會消耗占用掉系統的線程、io等資源，當該類請求越來越多，占用的計算機資源越來越多的時候，會導緻系統瓶頸出現，造成其他的請求同樣不可用，最終導緻業務系統崩潰。
一般情況對于服務依賴的保護主要有兩種方式：熔斷和限流。目前最流行的就是Hystrix的熔斷架構。
下圖是Hystrix的斷路器原理圖：
限流方式可以采用zuul的API限流方法。
18.Docker 容器部署技術&持續傳遞流水線
随着微服務的流行，容器技術也相應的被大家重視起來。容器技術主要解決了以下兩個問題：
1：環境一緻性問題。例如java的jar/war包部署會依賴于環境的問題（操着系統的版本，jdk版本問題）。
2：鏡像部署問題。例如java，rubby，nodejs等等的釋出系統是不一樣的，每個環境都得很麻煩的部署一遍，采用docker鏡像，就屏蔽了這類問題。
下圖是Docker容器部署的一個完整過程。
更重要的是，擁有如此多服務的叢集環境遷移、複制也非常輕松，隻需選擇好各服務對應的Docker服務鏡像、配置好互相之間通路位址就能很快搭建出一份完全一樣的新叢集。
19.容器排程和釋出體系
目前基于容器的排程平台有Kubernetes，mesos，omega。下圖是mesos的一個簡單架構示意圖。
下圖是一個完整的容器釋出體系
1.什麼是微服務