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

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

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

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

&

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

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

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