微服務(wù)設(shè)計入門課件

微服務(wù)設(shè)計入門設(shè)計分布式系統(tǒng)的常識和最佳實踐匯總主講人：李錕微服務(wù)設(shè)計入門設(shè)計分布式系統(tǒng)的常識和最佳實踐匯總1什么是微服務(wù)？全稱微服務(wù)架構(gòu)：MicroservicesArchitecture，縮寫為MSAMartinFowler的定義：微服務(wù)架構(gòu)是一種架構(gòu)模式，它提倡將單一應(yīng)用程序劃分為一組小的服務(wù)，服務(wù)之間互相協(xié)調(diào)、互相配合，為用戶提供最終價值。每個服務(wù)運行在其獨立的進程中，服務(wù)與服務(wù)間采用輕量級的通信機制互相溝通（通常是基于HTTP的RESTfulAPI）。每個服務(wù)都圍繞著具體業(yè)務(wù)進行構(gòu)建，并且能夠被獨立地部署在生產(chǎn)環(huán)境、預(yù)發(fā)布環(huán)境等。另外，應(yīng)盡量避免統(tǒng)一的、集中式的服務(wù)管理機制，對具體一個服務(wù)而言，應(yīng)根據(jù)應(yīng)用上下文，選擇合適的語言、工具對其進行構(gòu)建。什么是微服務(wù)？全稱微服務(wù)架構(gòu)：MicroservicesA2微服務(wù)架構(gòu)的幾大特征由一組小的服務(wù)組成一個完整的應(yīng)用（或網(wǎng)站）每個服務(wù)圍繞一個相對獨立的業(yè)務(wù)領(lǐng)域（領(lǐng)域模型）構(gòu)建服務(wù)之間通過輕量級的通信機制互相溝通完全去中心化每個服務(wù)都可以獨立部署每個服務(wù)可以使用不同的編程語言實現(xiàn)微服務(wù)架構(gòu)的幾大特征由一組小的服務(wù)組成一個完整的應(yīng)用（或網(wǎng)站3微服務(wù)設(shè)計入門課件4微服務(wù)架構(gòu)和傳統(tǒng)面向服務(wù)架構(gòu)（SOA）的區(qū)別SOA沒有為服務(wù)如何劃分提出具體指導(dǎo)SOA無法防止服務(wù)之間過度耦合SOA通常使用重量級的通信協(xié)議，例如SOAP/WSDLSOA中常常有集中式的服務(wù)管理機制，例如UDDI、ESBSOA未強調(diào)服務(wù)的獨立部署SOA難以使用不同的編程語言實現(xiàn)SOA的性能和可伸縮性無法滿足面向互聯(lián)網(wǎng)大流量應(yīng)用的需要微服務(wù)架構(gòu)和傳統(tǒng)面向服務(wù)架構(gòu)（SOA）的區(qū)別SOA沒有為服務(wù)5微服務(wù)設(shè)計入門課件6微服務(wù)架構(gòu)能帶來的好處——解決傳統(tǒng)單塊風格（monolithic

style）應(yīng)用的問題單一代碼庫，代碼維護復(fù)雜修改或新增代碼，影響范圍難以清晰估計迭代周期很長，難以制定周期固定的迭代開發(fā)計劃對程序員的技能要求很高單一發(fā)布單元，測試困難設(shè)計開發(fā)測試用例需要考慮的問題太多，包括驗收測試、回歸測試、性能測試微服務(wù)架構(gòu)能帶來的好處——解決傳統(tǒng)單塊風格（monolith7微服務(wù)架構(gòu)能帶來的好處——解決傳統(tǒng)單塊風格（monolithic

style）應(yīng)用的問題單一發(fā)布單元，發(fā)布困難可能需要停掉整個應(yīng)用（或網(wǎng)站）每次發(fā)布耗時很長：發(fā)布上百臺服務(wù)器、預(yù)發(fā)布環(huán)境大量的回歸測試……對服務(wù)器硬件配置要求極高，垂直擴展困難CPU、內(nèi)存、硬盤、網(wǎng)絡(luò)帶寬……無法做到無狀態(tài)，水平擴展困難無法實現(xiàn)線性水平擴展難以做容量規(guī)劃微服務(wù)架構(gòu)能帶來的好處——解決傳統(tǒng)單塊風格（monolith8微服務(wù)架構(gòu)能帶來的好處——解決集中式服務(wù)管理機制的問題常見集中式服務(wù)管理機制企業(yè)服務(wù)總線（ESB）Dubbo的服務(wù)注冊中心配置中心集中式服務(wù)管理機制的問題可伸縮性差，容易成為性能瓶頸有可能出現(xiàn)單點故障設(shè)計開發(fā)難度極高，因為要保證非常高的可用性（HA）微服務(wù)架構(gòu)能帶來的好處——解決集中式服務(wù)管理機制的問題常見集9微服務(wù)架構(gòu)能帶來的好處——解決重量級通信機制的問題常見的重量級通信機制基于HTTP的各種RPC（遠程過程調(diào)用）風格協(xié)議：SOAP/WSDL、XML-RPC、JSON-RPC、Burlap、Hessian二進制DO（分布式對象）風格協(xié)議：JavaRMI/EJB、.NETRemoting重量級通信機制的問題緊耦合：服務(wù)器端API做改動后，客戶端必須同時做改動、同時部署互操作性差：客戶端與服務(wù)器端常常需要使用相同的編程語言可伸縮性差：尤其是SOAP、XML-RPC微服務(wù)架構(gòu)能帶來的好處——解決重量級通信機制的問題常見的重量10設(shè)計微服務(wù)架構(gòu)需要掌握的基礎(chǔ)知識領(lǐng)域驅(qū)動設(shè)計（DDD）RESTfulAPI的設(shè)計以及深入理解HTTP協(xié)議一種RESTfulAPI開發(fā)框架Java：SpringMVC、Play、Jersey、RESTEasy、CXF.NET：ASP.NETWebAPINode.js：Express、Seneca

&

PM2Python：DjangoRESTFramework、FlaskRuby：Rails、Sinatra、Grape設(shè)計微服務(wù)架構(gòu)需要掌握的基礎(chǔ)知識領(lǐng)域驅(qū)動設(shè)計（DDD）11設(shè)計微服務(wù)架構(gòu)需要掌握的可選知識某種為部署微服務(wù)而設(shè)計的開發(fā)框架Java：SpringBoot、Dropwizard常用微服務(wù)運維工具服務(wù)自動負載均衡ConsulEureka：基于AWS的服務(wù)負載均衡NginxHAProxy日志、監(jiān)控ELK：

Elasticsearch/Logstash/KibanaZabbix基于Docker的部署和服務(wù)編排設(shè)計微服務(wù)架構(gòu)需要掌握的可選知識某種為部署微服務(wù)而設(shè)計的開發(fā)12設(shè)計微服務(wù)架構(gòu)需要解決的主要問題劃分服務(wù)的原則是什么？服務(wù)之間選擇何種輕量級的通信協(xié)議？如何做到服務(wù)的獨立部署？如何確定該使用何種服務(wù)編程語言？如何控制多語言帶來的復(fù)雜度？如何做到服務(wù)的去中心化？如何解決大量微服務(wù)引入的運維成本？設(shè)計微服務(wù)架構(gòu)需要解決的主要問題劃分服務(wù)的原則是什么？13劃分服務(wù)的原則是什么？參考DDD中的設(shè)計策略“界定的上下文”（BoundedContext），劃分出系統(tǒng)中不同的領(lǐng)域模型（上下文）每一個領(lǐng)域模型擁有自己獨立的數(shù)據(jù)庫（或其他持久存儲）DDD中其他對于劃分服務(wù)有參考價值的設(shè)計策略上下文映射（ContextMap）共享內(nèi)核（SharedKernel）客戶-供應(yīng)商（Customer-Supplier）順從者（Conformist）防崩潰層（AnticorruptionLayer）隔離通道（SeparateWay）開放主機服務(wù)（OpenHostService）劃分服務(wù)的原則是什么？參考DDD中的設(shè)計策略“界定的上下文”14劃分服務(wù)的原則是什么？判斷良好服務(wù)的標準自身保持高內(nèi)聚，有自己獨立的領(lǐng)域模型（上下文）封裝內(nèi)部變化，通過API對外暴露功能只有本服務(wù)自身的代碼可訪問本領(lǐng)域模型的數(shù)據(jù)庫其他系統(tǒng)只能通過本服務(wù)暴露的API間接訪問本服務(wù)的數(shù)據(jù)與其他服務(wù)保持松耦合，能夠獨立修改和部署依賴本服務(wù)的其他系統(tǒng)不必同時修改和部署能夠?qū)崿F(xiàn)服務(wù)自治，可獨立進化同一個領(lǐng)域模型（上下文）之上可以有多個發(fā)布單元，但是只有一個是服務(wù)常見的發(fā)布單元劃分方式：一個服務(wù)、一個定時任務(wù)、一個管理后臺劃分服務(wù)的原則是什么？判斷良好服務(wù)的標準15服務(wù)之間選擇何種輕量級的通信協(xié)議？API的實現(xiàn)技術(shù)應(yīng)該避免產(chǎn)生與客戶端的耦合例如JavaRMI，要求客戶端必須使用Java語言，耦合很強應(yīng)該選擇與具體技術(shù)不相關(guān)的API實現(xiàn)方式，以保證技術(shù)的選擇不被限制普通場合應(yīng)優(yōu)先選擇基于HTTP的RESTfulAPI基于HTTP協(xié)議，互操作性好，各種編程語言都支持可伸縮性好松耦合易于測試易于形成統(tǒng)一的編程風格服務(wù)之間選擇何種輕量級的通信協(xié)議？API的實現(xiàn)技術(shù)應(yīng)該避免產(chǎn)16服務(wù)之間選擇何種輕量級的通信協(xié)議？在特殊場合可以選擇二進制的RPC協(xié)議對低延遲、實時性要求極高服務(wù)的API極少變化，因此松耦合不重要可選的二進制的RPC協(xié)議：基于GoogleProtocol

Buffer數(shù)據(jù)交換格式的各種RPC協(xié)議基于ApacheThrift協(xié)議的各種RPC協(xié)議，例如唯品會的OSP不建議選擇基于HTTP的RPC協(xié)議緊耦合可伸縮性差服務(wù)之間選擇何種輕量級的通信協(xié)議？在特殊場合可以選擇二進制的17如何確定使用何種服務(wù)編程語言？優(yōu)先選擇團隊原先掌握的編程語言選擇另外一種互補性強的編程語言Java/C#與Node.js/Python/Ruby/Go根據(jù)對性能的要求性能要求高：Java/C#/Node.js/Go性能要求不高：Python/Ruby根據(jù)業(yè)務(wù)邏輯的變化頻繁程度業(yè)務(wù)邏輯相對固定：Java/C#業(yè)務(wù)邏輯可能經(jīng)常變化：Node.js/Python/Ruby如何確定使用何種服務(wù)編程語言？優(yōu)先選擇團隊原先掌握的編程語言18如何控制多語言帶來的復(fù)雜度在一個機構(gòu)內(nèi)，限制編程語言的數(shù)量服務(wù)編程語言限制在兩種以內(nèi)客戶端編程語言限制在兩種以內(nèi)建立統(tǒng)一的服務(wù)API設(shè)計風格例如各種語言都很容易實現(xiàn)的RESTfulAPI如何控制多語言帶來的復(fù)雜度在一個機構(gòu)內(nèi)，限制編程語言的數(shù)量19如何做到服務(wù)的獨立部署？盡量減少服務(wù)之間的依賴服務(wù)功能做到高內(nèi)聚API設(shè)計做到松耦合基于通用的通信機制，首選基于HTTP的RESTfulAPI服務(wù)API可做的獨立修改可自由添加非必需的請求參數(shù)可自由修改請求參數(shù)的類型可自由添加響應(yīng)參數(shù)可自由添加錯誤代碼可通過超文本通知客戶端相關(guān)聯(lián)的資源通過服務(wù)版本號控制不兼容的修改如何做到服務(wù)的獨立部署？盡量減少服務(wù)之間的依賴20如何做到服務(wù)的去中心化？不使用集中式的企業(yè)服務(wù)總線或服務(wù)注冊中心通過域名+URL來暴露服務(wù)使用Consul+DNS來做服務(wù)發(fā)現(xiàn)和自動負載均衡不使用集中式的配置中心配置信息由每個服務(wù)自行管理案例分析：2010年淘寶網(wǎng)的配置中心服務(wù)如何做到服務(wù)的去中心化？不使用集中式的企業(yè)服務(wù)總線或服務(wù)注冊21如何解決大量微服務(wù)引入的運維成本？能自動化的地方一定盡量自動化發(fā)布自動化測試自動化驗收測試、回歸測試、性能測試負載均衡自動化擴容、縮容自動化監(jiān)控自動化基于Docker容器部署基于云計算平臺部署如何解決大量微服務(wù)引入的運維成本？能自動化的地方一定盡量自動22基于Docker容器部署帶來的好處可以提高部署的自動化程度縮短部署時間，達到秒級部署可以提高測試環(huán)境與生產(chǎn)環(huán)境的一致性在測試環(huán)境中測出盡量多與環(huán)境有關(guān)的bug可以提高服務(wù)器硬件資源的利用效率可以實現(xiàn)自動化擴容、縮容基于Docker容器部署帶來的好處可以提高部署的自動化程度23基于云計算平臺部署帶來的好處可以帶來更好的可伸縮性水平擴展、垂直擴展都更容易可以帶來更好的容錯性可以很容易地添加各種新的能力例如阿里云所支持的大數(shù)據(jù)分析工具可以大幅降低運維的成本與應(yīng)用無關(guān)的系統(tǒng)級運維，由云計算平臺運營商負責應(yīng)用的運維團隊只需關(guān)注與應(yīng)用本身相關(guān)的運維基于云計算平臺部署帶來的好處可以帶來更好的可伸縮性24微服務(wù)和云計算平臺結(jié)合微服務(wù)和IaaS（基礎(chǔ)設(shè)施即服務(wù)）結(jié)合優(yōu)點：很容易提高硬件配置、自己可以完全控制、可移植性好缺點：自己需要做大量的運維工作微服務(wù)和PaaS（平臺即服務(wù)）結(jié)合優(yōu)點：不需要做大量的運維工作、缺點：控制力度很弱、可移植性差微服務(wù)和CaaS（容器即服務(wù)）結(jié)合優(yōu)點：不需要做大量的運維工作、控制力度強、可移植性好缺點：學習成本較高微服務(wù)和云計算平臺結(jié)合微服務(wù)和IaaS（基礎(chǔ)設(shè)施即服務(wù)）結(jié)合25不同團隊看待微服務(wù)的不同視角產(chǎn)品設(shè)計團隊視角更大的靈活性更強的響應(yīng)力開發(fā)團隊視角更便于維護更便于增量迭代式開發(fā)測試團隊視角更容易測試上線回歸時間更短運維團隊視角更好的可伸縮性、高可用性更容易部署更容易監(jiān)控不同團隊看待微服務(wù)的不同視角產(chǎn)品設(shè)計團隊視角26微服務(wù)系統(tǒng)的團隊管理康威定律（Conway’sLaw）任何組織在設(shè)計一套系統(tǒng)（廣義概念上的系統(tǒng)）時，所交付的設(shè)計方案在結(jié)構(gòu)來說，都會與該組織的溝通結(jié)構(gòu)保持一致。必須有整體的規(guī)劃和相關(guān)規(guī)范劃分界定的上下文根據(jù)界定的上下文劃分服務(wù)制定并維護服務(wù)設(shè)計規(guī)范、監(jiān)控規(guī)范微服務(wù)系統(tǒng)的團隊管理康威定律（Conway’sLaw）27微服務(wù)系統(tǒng)的團隊管理團隊組織應(yīng)與劃分的領(lǐng)域模型（上下文）匹配產(chǎn)品設(shè)計團隊開發(fā)團隊測試團隊充分授權(quán)讓小團隊完全擁有某個領(lǐng)域模型及其上服務(wù)的所有權(quán)所有權(quán)涵蓋需求、構(gòu)建、部署、運維等服務(wù)的全生命周期微服務(wù)系統(tǒng)的團隊管理團隊組織應(yīng)與劃分的領(lǐng)域模型（上下文）匹配28微服務(wù)設(shè)計入門課件29微服務(wù)的反模式——縱欲（Lust）：使用最新的、最牛x的技術(shù)現(xiàn)象：總是喜歡使用最新的、最牛x的技術(shù)DesignbyBuzzword解決方法：使用最適合目標、問題或需求用例的技術(shù)Docker、Kubernetes、Terraform，這些技術(shù)固然很好，并非一定要立即使用應(yīng)該鼓勵組織創(chuàng)建自己的策略，決定何時應(yīng)用這些創(chuàng)新技術(shù)在IT行業(yè)沒有銀彈：不要相信最新、最牛x的技術(shù)能夠解決你們所有的問題定義并深入理解你要解決的問題，是非常重要的調(diào)查你有哪些選項，創(chuàng)建文檔清晰地分析采用各種選項的理由、需求、產(chǎn)出，這可以幫助你做決策深入思考架構(gòu)、人員的技能評估、以及你的業(yè)務(wù)目標選擇落后技術(shù)沒什么丟人，只要這些技術(shù)能很好地解決問題微服務(wù)的反模式——縱欲（Lust）：使用最新的、最牛x的技術(shù)30微服務(wù)的反模式——饕餮（Gluttony）：使用過多的通信協(xié)議現(xiàn)象：使用了很多通信協(xié)議：HTTP、Protobuf、gRPC、Thrift、AMQP、MQTT解決方法嘗試對于通信協(xié)議進行標準化選擇一種同步通信協(xié)議，例如JSONoverHTTP（RESTfulAPI）選擇一種異步通信協(xié)議，例如RabbitMQ（AMQP）。別做鍍金之類的事情，夠用就好，但是要理解你還有哪些選項Protobuf、Thrift、ZeroMQ、MQTT微服務(wù)的反模式——饕餮（Gluttony）：使用過多的通信協(xié)31微服務(wù)的反模式——貪婪（Greed）：你們所有的服務(wù)都屬于我們現(xiàn)象：不理解引入微服務(wù)架構(gòu)對于組織、人和文化的影響不愿意重新劃分團隊解決方法：遵循一些團隊組織、項目管理的原則產(chǎn)品比項目更好小的跨學科團隊比大的同質(zhì)化團隊更好多個相互關(guān)聯(lián)的服務(wù)比單個復(fù)雜應(yīng)用更好目標驅(qū)動的技術(shù)領(lǐng)導(dǎo)力比命令+控制更好自動化的持續(xù)部署比手工完成大量工作更好個體和交互比過程和工具更好得到真實可用的功能比制定一堆最終被誤解的宣言更好微服務(wù)的反模式——貪婪（Greed）：你們所有的服務(wù)都屬于我32微服務(wù)的反模式——懶惰（Sloth）：創(chuàng)建了一個分布式的單塊應(yīng)用現(xiàn)象：無法獨立部署服務(wù)，多個相互依賴的、緊耦合的服務(wù)必須同時部署將設(shè)計單塊應(yīng)用的方法直接應(yīng)用到設(shè)計微服務(wù)上面，產(chǎn)生了很多小的單塊應(yīng)用。這些小的單塊應(yīng)用沒有擁抱單一職責原則（singleresponsibilityprinciple，SRP），相互之間依賴嚴重，導(dǎo)致必須采用復(fù)雜的部署過程。解決方法：需要密切關(guān)注服務(wù)的職責和API設(shè)計和協(xié)議必須是能夠自動化驗證并不斷強化的人類有喜歡走捷徑的天性，但是不要總是“走捷徑”微服務(wù)的反模式——懶惰（Sloth）：創(chuàng)建了一個分布式的單塊33微服務(wù)的反模式——暴怒（Wrath）：發(fā)生了糟糕的事情就會引發(fā)連鎖爆炸現(xiàn)象：因為某個消息隊列的擁塞，引發(fā)連鎖反應(yīng)，最終導(dǎo)致整個系統(tǒng)無法對外提供服務(wù)解決方法開發(fā)人員需要進行防御式編程，實現(xiàn)一些容錯模式，例如超時時間、重試機制、斷路器、艙壁等等。運維人員從思想和職責上需要擁抱DevOps，需要開發(fā)相關(guān)的工具鏈來支持快速供給、基礎(chǔ)監(jiān)控、快速應(yīng)用部署。必須把壓力傳遞給所有的運維和開發(fā)人員，應(yīng)該經(jīng)常搞災(zāi)難恢復(fù)演習一切問題都是人的問題！微服務(wù)的反模式——暴怒（Wrath）：發(fā)生了糟糕的事情就會引34微服務(wù)的反模式——嫉妒（Envy）：分享單個領(lǐng)域模型現(xiàn)象：為了滿足大量的報表/分析需求，使用單個大型數(shù)據(jù)庫，不愿意分割數(shù)據(jù)庫解決方法：通過ETL工具實現(xiàn)數(shù)據(jù)中心，匯集多個服務(wù)的數(shù)據(jù)在數(shù)據(jù)中心實現(xiàn)報表/分析需求微服務(wù)的反模式——嫉妒（Envy）：分享單個領(lǐng)域模型現(xiàn)象：35微服務(wù)的反模式——傲慢（Pride）：難以測試不穩(wěn)定的微服務(wù)系統(tǒng)現(xiàn)象：測試環(huán)境中各個服務(wù)都處在不穩(wěn)定的狀態(tài)，整體行為難以預(yù)測