注：文章內(nèi)容為摘錄性文字，自己閱讀的一些筆記，方便日后查看属韧。
微服務(wù)（Microservices）
在過去的 2016 年和 2017 年碗淌，微服務(wù)技術(shù)迅猛普及盏求，和容器技術(shù)一起成為這兩年中最吸引眼球的技術(shù)熱點(diǎn)。而以 Spring Cloud 為代表的傳統(tǒng)侵入式開發(fā)框架亿眠，占據(jù)著微服務(wù)市場(chǎng)的主流地位碎罚。
微服務(wù)（Microservices）是一種架構(gòu)風(fēng)格，一個(gè)大型復(fù)雜軟件應(yīng)用由一個(gè)或多個(gè)微服務(wù)組成纳像。系統(tǒng)中的各個(gè)微服務(wù)可被獨(dú)立部署荆烈，各個(gè)微服務(wù)之間是松耦合的。每個(gè)微服務(wù)僅關(guān)注于完成一件任務(wù)并很好地完成該任務(wù)竟趾。在所有情況下憔购，每個(gè)任務(wù)代表著一個(gè)小的業(yè)務(wù)能力。
形像一點(diǎn)來說岔帽，微服務(wù)架構(gòu)就像搭積木玫鸟，每個(gè)微服務(wù)都是一個(gè)零件，并使用這些零件組裝出不同的形狀犀勒。通俗來說屎飘，微服務(wù)架構(gòu)就是把一個(gè)大系統(tǒng)按業(yè)務(wù)功能分解成多個(gè)職責(zé)單一的小系統(tǒng)，并利用簡(jiǎn)單的方法使多個(gè)小系統(tǒng)相互協(xié)作账蓉，組合成一個(gè)大系統(tǒng)枚碗。
如果學(xué)科派一點(diǎn)，微服務(wù)架構(gòu)就是把因相同原因而變化的功能聚合到一起铸本，而把因不同原因而變化的功能分離開肮雨，并利用輕量化機(jī)制（通常為 HTTP RESTful API）實(shí)現(xiàn)通信。
微服務(wù)架構(gòu) ≈ 模塊化開發(fā) + 分布式計(jì)算箱玷。
需要注意的是“微服務(wù)”與“微服務(wù)架構(gòu)”是有本質(zhì)區(qū)別的怨规。“微服務(wù)”強(qiáng)調(diào)的是服務(wù)的大小锡足，它關(guān)注的是某一個(gè)點(diǎn)波丰。而“微服務(wù)架構(gòu)”則是一種架構(gòu)思想，需要從整體上對(duì)軟件系統(tǒng)進(jìn)行通盤的考慮舶得。
微服務(wù)架構(gòu)示意圖：
常見的微服務(wù)組件及概念：
服務(wù)注冊(cè)：服務(wù)提供方將自己調(diào)用地址注冊(cè)到服務(wù)注冊(cè)中心掰烟，讓服務(wù)調(diào)用方能夠方便地找到自己。
服務(wù)發(fā)現(xiàn)：服務(wù)調(diào)用方從服務(wù)注冊(cè)中心找到自己需要調(diào)用的服務(wù)的地址。
負(fù)載均衡：服務(wù)提供方一般以多實(shí)例的形式提供服務(wù)纫骑，負(fù)載均衡功能能夠讓服務(wù)調(diào)用方連接到合適的服務(wù)節(jié)點(diǎn)蝎亚。并且，節(jié)點(diǎn)選擇的工作對(duì)服務(wù)調(diào)用方來說是透明的先馆。
服務(wù)網(wǎng)關(guān)：服務(wù)網(wǎng)關(guān)是服務(wù)調(diào)用的唯一入口发框，可以在這個(gè)組件是實(shí)現(xiàn)用戶鑒權(quán)、動(dòng)態(tài)路由煤墙、灰度發(fā)布梅惯、A/B 測(cè)試、負(fù)載限流等功能仿野。
配置中心：將本地化的配置信息（properties, xml, yaml 等）注冊(cè)到配置中心铣减，實(shí)現(xiàn)程序包在開發(fā)、測(cè)試脚作、生產(chǎn)環(huán)境的無差別性徙歼，方便程序包的遷移。
API 管理：以方便的形式編寫及更新 API 文檔鳖枕，并以方便的形式供調(diào)用者查看和測(cè)試。
集成框架：微服務(wù)組件都以職責(zé)單一的程序包對(duì)外提供服務(wù)桨螺，集成框架以配置的形式將所有微服務(wù)組件（特別是管理端組件）集成到統(tǒng)一的界面框架下宾符，讓用戶能夠在統(tǒng)一的界面中使用系統(tǒng)。
分布式事務(wù)：對(duì)于重要的業(yè)務(wù)灭翔，需要通過分布式事務(wù)技術(shù)（TCC魏烫、高可用消息服務(wù)、最大努力通知）保證數(shù)據(jù)的一致性肝箱。
調(diào)用鏈：記錄完成一個(gè)業(yè)務(wù)邏輯時(shí)調(diào)用到的微服務(wù)哄褒，并將這種串行或并行的調(diào)用關(guān)系展示出來。在系統(tǒng)出錯(cuò)時(shí)煌张，可以方便地找到出錯(cuò)點(diǎn)呐赡。
支撐平臺(tái)：系統(tǒng)微服務(wù)化后，系統(tǒng)變得更加碎片化骏融，系統(tǒng)的部署链嘀、運(yùn)維、監(jiān)控等都比單體架構(gòu)更加復(fù)雜档玻，那么怀泊，就需要將大部分的工作自動(dòng)化。現(xiàn)在误趴，可以通過 Docker 等工具來中和這些微服務(wù)架構(gòu)帶來的弊端霹琼。 例如持續(xù)集成、藍(lán)綠發(fā)布、健康檢查枣申、性能健康等等售葡。嚴(yán)重點(diǎn)，以我們兩年的實(shí)踐經(jīng)驗(yàn)糯而，可以這么說天通，如果沒有合適的支撐平臺(tái)或工具，就不要使用微服務(wù)架構(gòu)熄驼。
微服務(wù)架構(gòu)的優(yōu)點(diǎn)：
降低系統(tǒng)復(fù)雜度：每個(gè)服務(wù)都比較簡(jiǎn)單像寒，只關(guān)注于一個(gè)業(yè)務(wù)功能。
松耦合：微服務(wù)架構(gòu)方式是松耦合的瓜贾，每個(gè)微服務(wù)可由不同團(tuán)隊(duì)獨(dú)立開發(fā)诺祸，互不影響。
跨語言：只要符合服務(wù) API 契約祭芦，開發(fā)人員可以自由選擇開發(fā)技術(shù)筷笨。這就意味著開發(fā)人員可以采用新技術(shù)編寫或重構(gòu)服務(wù)，由于服務(wù)相對(duì)較小龟劲，所以這并不會(huì)對(duì)整體應(yīng)用造成太大影響胃夏。
獨(dú)立部署：微服務(wù)架構(gòu)可以使每個(gè)微服務(wù)獨(dú)立部署。開發(fā)人員無需協(xié)調(diào)對(duì)服務(wù)升級(jí)或更改的部署昌跌。這些更改可以在測(cè)試通過后立即部署仰禀。所以微服務(wù)架構(gòu)也使得 CI／CD 成為可能。
Docker 容器：和 Docker 容器結(jié)合的更好蚕愤。
DDD 領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)：和 DDD 的概念契合答恶，結(jié)合開發(fā)會(huì)更好。
微服務(wù)架構(gòu)的缺點(diǎn)：
微服務(wù)強(qiáng)調(diào)了服務(wù)大小萍诱，但實(shí)際上這并沒有一個(gè)統(tǒng)一的標(biāo)準(zhǔn)：業(yè)務(wù)邏輯應(yīng)該按照什么規(guī)則劃分為微服務(wù)悬嗓，這本身就是一個(gè)經(jīng)驗(yàn)工程。有些開發(fā)者主張 10-100 行代碼就應(yīng)該建立一個(gè)微服務(wù)裕坊。雖然建立小型服務(wù)是微服務(wù)架構(gòu)崇尚的包竹，但要記住，微服務(wù)是達(dá)到目的的手段碍庵，而不是目標(biāo)映企。微服務(wù)的目標(biāo)是充分分解應(yīng)用程序，以促進(jìn)敏捷開發(fā)和持續(xù)集成部署静浴。
微服務(wù)的分布式特點(diǎn)帶來的復(fù)雜性：開發(fā)人員需要基于 RPC 或者消息實(shí)現(xiàn)微服務(wù)之間的調(diào)用和通信堰氓，而這就使得服務(wù)之間的發(fā)現(xiàn)、服務(wù)調(diào)用鏈的跟蹤和質(zhì)量問題變得的相當(dāng)棘手苹享。
分區(qū)的數(shù)據(jù)庫(kù)體系和分布式事務(wù)：更新多個(gè)業(yè)務(wù)實(shí)體的業(yè)務(wù)交易相當(dāng)普遍双絮，不同服務(wù)可能擁有不同的數(shù)據(jù)庫(kù)浴麻。CAP 原理的約束，使得我們不得不放棄傳統(tǒng)的強(qiáng)一致性囤攀，而轉(zhuǎn)而追求最終一致性软免，這個(gè)對(duì)開發(fā)人員來說是一個(gè)挑戰(zhàn)。
測(cè)試挑戰(zhàn)：傳統(tǒng)的單體WEB應(yīng)用只需測(cè)試單一的 REST API 即可焚挠，而對(duì)微服務(wù)進(jìn)行測(cè)試膏萧，需要啟動(dòng)它依賴的所有其他服務(wù)。這種復(fù)雜性不可低估蝌衔。
跨多個(gè)服務(wù)的更改：比如在傳統(tǒng)單體應(yīng)用中榛泛，若有 A、B噩斟、C 三個(gè)服務(wù)需要更改曹锨，A 依賴 B，B 依賴 C剃允。我們只需更改相應(yīng)的模塊沛简，然后一次性部署即可。但是在微服務(wù)架構(gòu)中斥废，我們需要仔細(xì)規(guī)劃和協(xié)調(diào)每個(gè)服務(wù)的變更部署椒楣。我們需要先更新 C，然后更新 B牡肉，最后更新 A撒顿。
部署復(fù)雜：微服務(wù)由不同的大量服務(wù)構(gòu)成。每種服務(wù)可能擁有自己的配置荚板、應(yīng)用實(shí)例數(shù)量以及基礎(chǔ)服務(wù)地址。這里就需要不同的配置吩屹、部署跪另、擴(kuò)展和監(jiān)控組件。此外煤搜，我們還需要服務(wù)發(fā)現(xiàn)機(jī)制免绿，以便服務(wù)可以發(fā)現(xiàn)與其通信的其他服務(wù)的地址。因此擦盾，成功部署微服務(wù)應(yīng)用需要開發(fā)人員有更好地部署策略和高度自動(dòng)化的水平嘲驾。
總的來說（問題和挑戰(zhàn)）：API Gateway、服務(wù)間調(diào)用迹卢、服務(wù)發(fā)現(xiàn)辽故、服務(wù)容錯(cuò)丙猬、服務(wù)部署翁潘、數(shù)據(jù)調(diào)用。
不過戒财，現(xiàn)在很多微服務(wù)的框架（比如 Spring Cloud、Dubbo）已經(jīng)很好的解決了上面的問題喂走。
資料來源：
微服務(wù)架構(gòu)初探（很贊殃饿，推薦）
解析微服務(wù)架構(gòu)(一)：什么是微服務(wù)
從0開始的微服務(wù)架構(gòu)：（一）重識(shí)微服務(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)控携取。對(duì)于編寫應(yīng)用程序來說一般無須關(guān)心 TCP/IP 這一層（比如通過 HTTP 協(xié)議的 RESTful 應(yīng)用），同樣使用 Service Mesh 也就無須關(guān)系服務(wù)之間的那些原來是通過應(yīng)用程序或者其他框架實(shí)現(xiàn)的事情帮孔，比如 Spring Cloud雷滋、OSS，現(xiàn)在只要交給 Service Mesh 就可以了文兢。
Service Mesh 的來龍去脈：
從最原始的主機(jī)之間直接使用網(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)和斷路器的軟件包/庫(kù)晤斩，如 Twitter 的 Finagle 和 Facebook 的 Proxygen，這時(shí)候還是集成在應(yīng)用程序內(nèi)部
出現(xiàn)了專門用于服務(wù)發(fā)現(xiàn)和斷路器的開源軟件姆坚，如 Netflix OSS澳泵、Airbnb 的 synapse 和 nerve
最后作為微服務(wù)的中間層 Service Mesh 出現(xiàn)
Service Mesh 有如下幾個(gè)特點(diǎn)：
應(yīng)用程序間通訊的中間層
輕量級(jí)網(wǎng)絡(luò)代理
應(yīng)用程序無感知
解耦應(yīng)用程序的重試/超時(shí)、監(jiān)控兼呵、追蹤和服務(wù)發(fā)現(xiàn)
Service Mesh 架構(gòu)圖：
目前流行的 Service Mesh 開源軟件有 Linkerd兔辅、Envoy 和 Istio，而最近 Buoyant（開源 Linkerd 的公司）又發(fā)布了基于 Kubernetes 的 Service Mesh 開源項(xiàng)目 Conduit击喂。
Service Mesh 開源項(xiàng)目簡(jiǎn)介：
Linkerd（https://github.com/linkerd/linkerd）：第一代 Service Mesh维苔，2016 年 1 月 15 日首發(fā)布，業(yè)界第一個(gè) Service Mesh 項(xiàng)目懂昂，由 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 個(gè)人開發(fā)（Lyft 工程師）褐澎，之后默默發(fā)展，版本較穩(wěn)定伐蒋。
Istio（https://github.com/istio/istio）：第二代 Service Mesh乱凿，2017 年 5 月 24 日首發(fā)布顽素，由 Google、IBM 和 Lyft 聯(lián)合開發(fā)徒蟆，只支持 Kubernetes 平臺(tái)胁出，2017 年 11 月 30 日發(fā)布 0.3 版本，開始支持非 Kubernetes 平臺(tái)段审，之后穩(wěn)定的開發(fā)和發(fā)布全蝶。
Conduit（https://github.com/runconduit/conduit）：第二代 Service Mesh，2017 年 12 月 5 日首發(fā)布寺枉，由 Buoyant 公司開發(fā)（借鑒 Istio 整體架構(gòu)抑淫，部分進(jìn)行了優(yōu)化），對(duì)抗 ?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ù)更像是一個(gè)服務(wù)之間的生態(tài)账锹，專注于服務(wù)治理等方面萌业，而服務(wù)網(wǎng)格更專注于服務(wù)之間的通信，以及和 DevOps 更好的結(jié)合奸柬。
資料來源：
什么是 Service Mesh（服務(wù)網(wǎng)格）（很贊咽白，推薦）
解讀2017之Service Mesh：群雄逐鹿烽煙起（很贊，推薦）
轉(zhuǎn)載地址:https://www.cnblogs.com/xishuai/p/microservices-and-service-mesh.html
