注：文章內(nèi)容為摘錄性文字跌捆，自己閱讀的一些筆記佩厚，方便日后查看说订。
微服務(wù)（Microservices）
在過去的 2016 年和 2017 年，微服務(wù)技術(shù)迅猛普及闺鲸，和容器技術(shù)一起成為這兩年中最吸引眼球的技術(shù)熱點埃叭。而以 Spring Cloud 為代表的傳統(tǒng)侵入式開發(fā)框架摸恍，占據(jù)著微服務(wù)市場的主流地位赤屋。
微服務(wù)（Microservices）是一種架構(gòu)風(fēng)格，一個大型復(fù)雜軟件應(yīng)用由一個或多個微服務(wù)組成类早。系統(tǒng)中的各個微服務(wù)可被獨立部署，各個微服務(wù)之間是松耦合的缭召。每個微服務(wù)僅關(guān)注于完成一件任務(wù)并很好地完成該任務(wù)栈顷。在所有情況下嵌巷，每個任務(wù)代表著一個小的業(yè)務(wù)能力。
形像一點來說搪哪，微服務(wù)架構(gòu)就像搭積木，每個微服務(wù)都是一個零件晓折，并使用這些零件組裝出不同的形狀。通俗來說漓概，微服務(wù)架構(gòu)就是把一個大系統(tǒng)按業(yè)務(wù)功能分解成多個職責(zé)單一的小系統(tǒng)，并利用簡單的方法使多個小系統(tǒng)相互協(xié)作栅屏，組合成一個大系統(tǒng)。
如果學(xué)科派一點栈雳，微服務(wù)架構(gòu)就是把因相同原因而變化的功能聚合到一起缔莲，而把因不同原因而變化的功能分離開哥纫，并利用輕量化機制（通常為 HTTP RESTful API）實現(xiàn)通信痴奏。
微服務(wù)架構(gòu) ≈ 模塊化開發(fā) + 分布式計算。
需要注意的是“微服務(wù)”與“微服務(wù)架構(gòu)”是有本質(zhì)區(qū)別的读拆。“微服務(wù)”強調(diào)的是服務(wù)的大小暑诸，它關(guān)注的是某一個點。而“微服務(wù)架構(gòu)”則是一種架構(gòu)思想个榕，需要從整體上對軟件系統(tǒng)進行通盤的考慮。
微服務(wù)架構(gòu)示意圖：
常見的微服務(wù)組件及概念：
服務(wù)注冊：服務(wù)提供方將自己調(diào)用地址注冊到服務(wù)注冊中心西采，讓服務(wù)調(diào)用方能夠方便地找到自己。
服務(wù)發(fā)現(xiàn)：服務(wù)調(diào)用方從服務(wù)注冊中心找到自己需要調(diào)用的服務(wù)的地址械馆。
負(fù)載均衡：服務(wù)提供方一般以多實例的形式提供服務(wù)胖眷，負(fù)載均衡功能能夠讓服務(wù)調(diào)用方連接到合適的服務(wù)節(jié)點。并且狱杰，節(jié)點選擇的工作對服務(wù)調(diào)用方來說是透明的瘦材。
服務(wù)網(wǎng)關(guān)：服務(wù)網(wǎng)關(guān)是服務(wù)調(diào)用的唯一入口，可以在這個組件是實現(xiàn)用戶鑒權(quán)仿畸、動態(tài)路由、灰度發(fā)布朗和、A/B 測試错沽、負(fù)載限流等功能。
配置中心：將本地化的配置信息（properties, xml, yaml 等）注冊到配置中心眶拉，實現(xiàn)程序包在開發(fā)千埃、測試、生產(chǎn)環(huán)境的無差別性忆植，方便程序包的遷移。
API 管理：以方便的形式編寫及更新 API 文檔朝刊，并以方便的形式供調(diào)用者查看和測試耀里。
集成框架：微服務(wù)組件都以職責(zé)單一的程序包對外提供服務(wù)，集成框架以配置的形式將所有微服務(wù)組件（特別是管理端組件）集成到統(tǒng)一的界面框架下拾氓，讓用戶能夠在統(tǒng)一的界面中使用系統(tǒng)冯挎。
分布式事務(wù)：對于重要的業(yè)務(wù)，需要通過分布式事務(wù)技術(shù)（TCC咙鞍、高可用消息服務(wù)房官、最大努力通知）保證數(shù)據(jù)的一致性。
調(diào)用鏈：記錄完成一個業(yè)務(wù)邏輯時調(diào)用到的微服務(wù)续滋，并將這種串行或并行的調(diào)用關(guān)系展示出來翰守。在系統(tǒng)出錯時，可以方便地找到出錯點疲酌。
支撐平臺：系統(tǒng)微服務(wù)化后蜡峰，系統(tǒng)變得更加碎片化徐勃，系統(tǒng)的部署事示、運維僻肖、監(jiān)控等都比單體架構(gòu)更加復(fù)雜肖爵，那么，就需要將大部分的工作自動化⊥卧啵現(xiàn)在劝堪，可以通過 Docker 等工具來中和這些微服務(wù)架構(gòu)帶來的弊端冀自。 例如持續(xù)集成、藍綠發(fā)布秒啦、健康檢查熬粗、性能健康等等。嚴(yán)重點余境，以我們兩年的實踐經(jīng)驗驻呐，可以這么說，如果沒有合適的支撐平臺或工具芳来，就不要使用微服務(wù)架構(gòu)佣盒。
微服務(wù)架構(gòu)的優(yōu)點：
降低系統(tǒng)復(fù)雜度：每個服務(wù)都比較簡單肥惭，只關(guān)注于一個業(yè)務(wù)功能蜜葱。
松耦合：微服務(wù)架構(gòu)方式是松耦合的笼沥，每個微服務(wù)可由不同團隊獨立開發(fā)，互不影響汹桦。
跨語言：只要符合服務(wù) API 契約舞骆，開發(fā)人員可以自由選擇開發(fā)技術(shù)督禽。這就意味著開發(fā)人員可以采用新技術(shù)編寫或重構(gòu)服務(wù)，由于服務(wù)相對較小胧谈，所以這并不會對整體應(yīng)用造成太大影響菱肖。
獨立部署：微服務(wù)架構(gòu)可以使每個微服務(wù)獨立部署场仲。開發(fā)人員無需協(xié)調(diào)對服務(wù)升級或更改的部署燎窘。這些更改可以在測試通過后立即部署。所以微服務(wù)架構(gòu)也使得 CI／CD 成為可能。
Docker 容器：和 Docker 容器結(jié)合的更好俊抵。
DDD 領(lǐng)域驅(qū)動設(shè)計：和 DDD 的概念契合徽诲，結(jié)合開發(fā)會更好。
微服務(wù)架構(gòu)的缺點：
微服務(wù)強調(diào)了服務(wù)大小钱贯，但實際上這并沒有一個統(tǒng)一的標(biāo)準(zhǔn)：業(yè)務(wù)邏輯應(yīng)該按照什么規(guī)則劃分為微服務(wù)，這本身就是一個經(jīng)驗工程弃锐。有些開發(fā)者主張 10-100 行代碼就應(yīng)該建立一個微服務(wù)。雖然建立小型服務(wù)是微服務(wù)架構(gòu)崇尚的浇辜，但要記住柳洋，微服務(wù)是達到目的的手段卑雁，而不是目標(biāo)测蹲。微服務(wù)的目標(biāo)是充分分解應(yīng)用程序，以促進敏捷開發(fā)和持續(xù)集成部署。
微服務(wù)的分布式特點帶來的復(fù)雜性：開發(fā)人員需要基于 RPC 或者消息實現(xiàn)微服務(wù)之間的調(diào)用和通信示辈，而這就使得服務(wù)之間的發(fā)現(xiàn)矾麻、服務(wù)調(diào)用鏈的跟蹤和質(zhì)量問題變得的相當(dāng)棘手险耀。
分區(qū)的數(shù)據(jù)庫體系和分布式事務(wù)：更新多個業(yè)務(wù)實體的業(yè)務(wù)交易相當(dāng)普遍，不同服務(wù)可能擁有不同的數(shù)據(jù)庫柴灯。CAP 原理的約束，使得我們不得不放棄傳統(tǒng)的強一致性查描，而轉(zhuǎn)而追求最終一致性匀油，這個對開發(fā)人員來說是一個挑戰(zhàn)窝爪。
測試挑戰(zhàn)：傳統(tǒng)的單體WEB應(yīng)用只需測試單一的 REST API 即可，而對微服務(wù)進行測試望蜡，需要啟動它依賴的所有其他服務(wù)状您。這種復(fù)雜性不可低估柒桑。
跨多個服務(wù)的更改：比如在傳統(tǒng)單體應(yīng)用中，若有 A、B、C 三個服務(wù)需要更改氯庆，A 依賴 B实昨，B 依賴 C志电。我們只需更改相應(yīng)的模塊洒嗤，然后一次性部署即可间唉。但是在微服務(wù)架構(gòu)中际跪，我們需要仔細規(guī)劃和協(xié)調(diào)每個服務(wù)的變更部署玛追。我們需要先更新 C，然后更新 B佛析，最后更新 A。
部署復(fù)雜：微服務(wù)由不同的大量服務(wù)構(gòu)成。每種服務(wù)可能擁有自己的配置、應(yīng)用實例數(shù)量以及基礎(chǔ)服務(wù)地址敬特。這里就需要不同的配置、部署皱炉、擴展和監(jiān)控組件怀估。此外，我們還需要服務(wù)發(fā)現(xiàn)機制合搅，以便服務(wù)可以發(fā)現(xiàn)與其通信的其他服務(wù)的地址多搀。因此，成功部署微服務(wù)應(yīng)用需要開發(fā)人員有更好地部署策略和高度自動化的水平灾部。
總的來說（問題和挑戰(zhàn)）：API Gateway康铭、服務(wù)間調(diào)用、服務(wù)發(fā)現(xiàn)梳猪、服務(wù)容錯麻削、服務(wù)部署、數(shù)據(jù)調(diào)用春弥。
不過呛哟，現(xiàn)在很多微服務(wù)的框架（比如 Spring Cloud、Dubbo）已經(jīng)很好的解決了上面的問題匿沛。
資料來源：
微服務(wù)架構(gòu)初探（很贊扫责，推薦）
解析微服務(wù)架構(gòu)(一)：什么是微服務(wù)
從0開始的微服務(wù)架構(gòu)：（一）重識微服務(wù)架構(gòu)
服務(wù)網(wǎng)格（Service Mesh）
2017 年底，非侵入式的 Service Mesh 技術(shù)從萌芽到走向了成熟逃呼。
Service Mesh 又譯作“服務(wù)網(wǎng)格”鳖孤，作為服務(wù)間通信的基礎(chǔ)設(shè)施層。
如果用一句話來解釋什么是 Service Mesh抡笼，可以將它比作是應(yīng)用程序或者說微服務(wù)間的 TCP/IP苏揣，負(fù)責(zé)服務(wù)之間的網(wǎng)絡(luò)調(diào)用、限流推姻、熔斷和監(jiān)控平匈。對于編寫應(yīng)用程序來說一般無須關(guān)心 TCP/IP 這一層（比如通過 HTTP 協(xié)議的 RESTful 應(yīng)用），同樣使用 Service Mesh 也就無須關(guān)系服務(wù)之間的那些原來是通過應(yīng)用程序或者其他框架實現(xiàn)的事情藏古，比如 Spring Cloud增炭、OSS，現(xiàn)在只要交給 Service Mesh 就可以了拧晕。
Service Mesh 的來龍去脈：
從最原始的主機之間直接使用網(wǎng)線相連
網(wǎng)絡(luò)層的出現(xiàn)
集成到應(yīng)用程序內(nèi)部的控制流
分解到應(yīng)用程序外部的控制流
應(yīng)用程序的中集成服務(wù)發(fā)現(xiàn)和斷路器
出現(xiàn)了專門用于服務(wù)發(fā)現(xiàn)和斷路器的軟件包/庫隙姿，如 Twitter 的 Finagle 和 Facebook 的 Proxygen，這時候還是集成在應(yīng)用程序內(nèi)部
出現(xiàn)了專門用于服務(wù)發(fā)現(xiàn)和斷路器的開源軟件厂捞，如 Netflix OSS输玷、Airbnb 的 synapse 和 nerve
最后作為微服務(wù)的中間層 Service Mesh 出現(xiàn)
Service Mesh 有如下幾個特點：
應(yīng)用程序間通訊的中間層
輕量級網(wǎng)絡(luò)代理
應(yīng)用程序無感知
解耦應(yīng)用程序的重試/超時队丝、監(jiān)控、追蹤和服務(wù)發(fā)現(xiàn)
Service Mesh 架構(gòu)圖：
目前流行的 Service Mesh 開源軟件有 Linkerd饲嗽、Envoy 和 Istio炭玫，而最近 Buoyant（開源 Linkerd 的公司）又發(fā)布了基于 Kubernetes 的 Service Mesh 開源項目 Conduit。
Service Mesh 開源項目簡介：
Linkerd（https://github.com/linkerd/linkerd）：第一代 Service Mesh貌虾，2016 年 1 月 15 日首發(fā)布吞加，業(yè)界第一個 Service Mesh 項目，由 Buoyant 創(chuàng)業(yè)小公司開發(fā)（前 Twitter 工程師）尽狠，2017 年 7 月 11 日衔憨，宣布和 Istio 集成，成為 Istio 的數(shù)據(jù)面板袄膏。
Envoy（https://github.com/envoyproxy/envoy）：第一代 Service Mesh践图，2016 年 9 月 13 日首發(fā)布，由 Matt Klein 個人開發(fā)（Lyft 工程師）沉馆，之后默默發(fā)展码党，版本較穩(wěn)定。
Istio（https://github.com/istio/istio）：第二代 Service Mesh斥黑，2017 年 5 月 24 日首發(fā)布揖盘，由 Google、IBM 和 Lyft 聯(lián)合開發(fā)锌奴，只支持 Kubernetes 平臺兽狭，2017 年 11 月 30 日發(fā)布 0.3 版本，開始支持非 Kubernetes 平臺鹿蜀，之后穩(wěn)定的開發(fā)和發(fā)布箕慧。
Conduit（https://github.com/runconduit/conduit）：第二代 Service Mesh，2017 年 12 月 5 日首發(fā)布茴恰，由 Buoyant 公司開發(fā)（借鑒 Istio 整體架構(gòu)颠焦，部分進行了優(yōu)化），對抗 Istio 壓力山大往枣，也期待 Buoyant 公司的毅力伐庭。
nginMesh（https://github.com/nginmesh/nginmesh）：2017 年 9 月首發(fā)布，由 Nginx 開發(fā)婉商，定位是作為 Istio 的服務(wù)代理，也就是替代 Envoy渣叛，思路跟 Linkerd 之前和 Istio 集成很相似丈秩，極度低調(diào)，GitHub 上的 star 也只有不到 100淳衙。
Kong（https://github.com/Kong/kong）：比 nginMesh 更加低調(diào)蘑秽，默默發(fā)展中饺著。
關(guān)于微服務(wù)和服務(wù)網(wǎng)格的區(qū)別，我的一些理解：微服務(wù)更像是一個服務(wù)之間的生態(tài)肠牲，專注于服務(wù)治理等方面幼衰，而服務(wù)網(wǎng)格更專注于服務(wù)之間的通信，以及和 DevOps 更好的結(jié)合缀雳。
資料來源：
什么是 Service Mesh（服務(wù)網(wǎng)格）（很贊渡嚣，推薦）
解讀2017之Service Mesh：群雄逐鹿烽煙起（很贊，推薦）
