傳統(tǒng)行業(yè)向互聯(lián)網(wǎng)行業(yè)的轉(zhuǎn)型

背景

2012年以后，因為移動互聯(lián)網(wǎng)的興起窟哺，隨著網(wǎng)名數(shù)量的增多，需求變化大技肩，用戶群體大且轨。導(dǎo)致已有的應(yīng)用程序無法抗住大規(guī)模的并發(fā)浮声，且版本迭代麻煩，擴展不夠靈活旋奢，應(yīng)對外界環(huán)境能力薄弱泳挥，所以微服務(wù)思想就應(yīng)運而生了。

2014年微服務(wù)的概念傳入中國至朗，2015年左右國內(nèi)大廠開始進行項目升級屉符，轉(zhuǎn)戰(zhàn)微服務(wù)。2018年中小型企業(yè)也開始進行微服務(wù)架構(gòu)升級锹引。

傳統(tǒng)行業(yè)的產(chǎn)品是必然要向互聯(lián)網(wǎng)行業(yè)進行轉(zhuǎn)型的矗钟，馬云爸爸曾經(jīng)說過：如果說傳統(tǒng)制造業(yè)不擁抱互聯(lián)網(wǎng)的話，那注定是死路一條嫌变。而轉(zhuǎn)型的過程當中吨艇，底層的架構(gòu)模式也不再是傳統(tǒng)的單體架構(gòu)了，而是全新的微服務(wù)架構(gòu)模式腾啥。

馬云曾說道：十五年以前东涡，我在全國各地，至少兩三年內(nèi)講過兩三百次這樣的演講倘待，提醒大家互聯(lián)網(wǎng)疮跑、電子商務(wù)對各行各業(yè)會有沖擊，但是沒有人把這個話當回事情凸舵，那個時候我是Nobody祖娘，講話等于白講。但是今天贞间，既然我已經(jīng)有這樣的資源贿条，我還是要告訴大家，未來二三十年增热，這個世界的變化超過所有人的想象力，而且絕大部分人是很倒霉的胧辽。今天的傳統(tǒng)企業(yè)如果依然固步自封峻仇，不接受新時代和新的商業(yè)模式，勢必會被淘汰邑商。

傳統(tǒng)行業(yè)與互聯(lián)網(wǎng)行業(yè)的區(qū)別

互聯(lián)網(wǎng)發(fā)展史

web 1.0

用戶只能搜索和閱讀網(wǎng)絡(luò)信息摄咆。比如中國的幾大門戶網(wǎng)站：搜狐、新浪人断、網(wǎng)易吭从、騰訊，平臺提供內(nèi)容和數(shù)據(jù)恶迈，用戶被動接受涩金，和用戶缺乏交互。

web 2.0

用戶能夠創(chuàng)造內(nèi)容，并分享在網(wǎng)路平臺上跟大家進行互動步做，而不再只是單純的訪問者副渴；這種范式的發(fā)展重新定義了市場和商業(yè)模式。比如QQ全度、天涯煮剧、微博、淘寶将鸵、美團勉盅、滴滴，提供一個平臺顶掉，用戶你們自己玩菇篡。用戶需要注冊，用戶和平臺交互變得很強一喘，用戶和用戶之間可以交流驱还，數(shù)據(jù)幾乎由用戶產(chǎn)生。

web 3.0

網(wǎng)絡(luò)在接受信息的同時凸克，通過數(shù)據(jù)分析议蟆，能夠根據(jù)用戶的喜好產(chǎn)生出新的數(shù)據(jù)和信息并推送給用戶。比如網(wǎng)易云音樂的推薦萎战，搜索引擎的推薦咐容，淘寶的商品推薦，地圖應(yīng)用的出行規(guī)劃蚂维，堵車預(yù)測等等戳粒。其特征是使用 web 2.0 時代所產(chǎn)生的大量數(shù)據(jù)，更加精準虫啥、實時和深入的為用戶提供服務(wù)蔚约。一個簡單的例子：當你在淘寶上買了某件商品后，訂單下方會出現(xiàn)很多類似商品推送涂籽。

總結(jié)

比如：你家樓下餐館代表互聯(lián)網(wǎng)苹祟，你飾演互聯(lián)網(wǎng)用戶。

• WEB1.0時代：你晚上一進餐館评雌，老板給你上了一桌子菜树枫，說兄弟都是你的吃吧！（不分析）你自己挨個嘗試景东，因為你不知道哪個菜好吃砂轻。（缺乏交互）
• WEB2.0時代：你晚上一進餐館，你說：老板來斤餃子斤吐。老板說：沒有餃子有面條搔涝。你說來碗面條厨喂，老板給你上了一碗面條。（被動分析）或者体谒，你不知道吃什么好杯聚，但是坐在你旁邊的食客會告訴你哪個好吃。（用戶交互）
• WEB3.0時代：你晚上一進餐館抒痒，一進門老板就說：客官幌绍，來碗面條吧！你問為啥故响，老板說傀广，你連續(xù)吃一禮拜面條了。（主動分析）WEB 3.0 是微服務(wù)彩届、大數(shù)據(jù)伪冰、云計算、人工智能的時代樟蠕。

技術(shù)架構(gòu)演變

下圖表示從單體應(yīng)用逐漸轉(zhuǎn)變?yōu)槲⒎?wù)應(yīng)用贮聂。

單一應(yīng)用架構(gòu)

通俗地講，“單體應(yīng)用（monolith application）”就是將應(yīng)用程序的所有功能都打包成一個獨立的單元寨辩。當網(wǎng)站流量很小時吓懈，只需一個應(yīng)用巩踏，將所有功能都部署在一起限府，以減少部署節(jié)點和成本艳吠。

特點

• 所有的功能集成在一個項目工程中呢蔫；
• 所有的功能打一個 war 包部署到服務(wù)器；
• 應(yīng)用與數(shù)據(jù)庫分開部署挠羔；
• 通過部署應(yīng)用集群和數(shù)據(jù)庫集群來提高系統(tǒng)的性能友浸。

優(yōu)點：

• 開發(fā)簡單：一個 IDE 就可以快速構(gòu)建單體應(yīng)用拆又；

• 便于共享：單個歸檔文件包含所有功能梢杭，便于在團隊之間以及不同的部署階段之間共享温兼；

• 易于測試：單體應(yīng)用一旦部署，所有的服務(wù)或特性就都可以使用了式曲，這簡化了測試過程妨托，因為沒有額外的依賴，每項測試都可以在部署完成后立刻開始吝羞；

• 容易部署：整個項目就一個 war 包，Tomcat 安裝好之后内颗，應(yīng)用扔上去就行了钧排。群化部署也很容易，多個 Tomcat + 一個 Nginx 分分鐘搞定均澳。

缺點：

• 妨礙持續(xù)交付：隨著時間的推移恨溜，單體應(yīng)用可能會變得比較大符衔，構(gòu)建和部署時間也相應(yīng)地延長，不利于頻繁部署糟袁，阻礙持續(xù)交付判族。在移動應(yīng)用開發(fā)中，這個問題會顯得尤為嚴重项戴；
• 不夠靈活：隨著項目的逐漸變大形帮，整個開發(fā)流程的時間也會變得很長，即使在僅僅更改了一行代碼的情況下周叮，軟件開發(fā)人員需要花費幾十分鐘甚至超過一個小時的時間對所有代碼進行編譯辩撑，并接下來花費大量的時間重新部署剛剛生成的產(chǎn)品，以驗證自己的更改是否正確仿耽。如果多個開發(fā)人員共同開發(fā)一個應(yīng)用程序合冀，那么還要等待其他開發(fā)人員完成了各自的開發(fā)。這降低了團隊的靈活性和功能交付頻率项贺；
• 受技術(shù)棧限制：項目變得越來越大的同時君躺，我們的應(yīng)用所使用的技術(shù)也會變得越來越多。這些技術(shù)有些是不兼容的开缎，就比如在一個項目中大范圍地混合使用 C++ 和 Java 幾乎是不可能的事情棕叫。在這種情況下，我們就需要拋棄對某些不兼容技術(shù)的使用啥箭，而選擇一種不是那么適合的技術(shù)來實現(xiàn)特定的功能谍珊。
• 可靠性差：某個環(huán)節(jié)出現(xiàn)了死循環(huán)，導(dǎo)致內(nèi)存溢出急侥，會影響整個項目掛掉砌滞。
• 伸縮性差：系統(tǒng)的擴容只能針對應(yīng)用進行擴容，不能做到對某個功能進行擴容坏怪，擴容后必然帶來資源浪費的問題贝润。
• 技術(shù)債務(wù)：假設(shè)我的代碼庫中有一個混亂的模塊結(jié)構(gòu)。此時铝宵，我需要添加一個新功能打掘。如果這個模塊結(jié)構(gòu)清晰，可能我只需要2天時間就可以添加好這個功能鹏秋，但是如今這個模塊的結(jié)構(gòu)很混亂尊蚁，所以我需要4天時間。多出來的這兩天就是債務(wù)利息侣夷。隨著時間推移横朋、人員變動，技術(shù)債務(wù)必然也會隨之增多百拓。

垂直應(yīng)用架構(gòu)

當訪問量逐漸增大琴锭，單一應(yīng)用增加機器帶來的加速度越來越小晰甚，將應(yīng)用拆成互不相干的幾個應(yīng)用，以提升效率决帖。

特點

• 以單體結(jié)構(gòu)規(guī)模的項目為單位進行垂直劃分厕九，就是將一個大項目拆分成一個一個單體結(jié)構(gòu)項目。
• 項目與項目之間存在數(shù)據(jù)冗余地回，耦合性較大扁远，比如上圖中三個項目都存在用戶信息。
• 項目之間的接口多為數(shù)據(jù)同步功能落君，如：數(shù)據(jù)庫之間的數(shù)據(jù)庫穿香，通過網(wǎng)絡(luò)接口進行數(shù)據(jù)庫同步。

優(yōu)點

• 開發(fā)成本低绎速，架構(gòu)簡單皮获；

• 避免單體應(yīng)用的無限擴大；

• 系統(tǒng)拆分實現(xiàn)了流量分擔(dān)纹冤，解決了并發(fā)問題洒宝；

• 可以針對不同系統(tǒng)進行擴容、優(yōu)化萌京；

• 方便水平擴展雁歌，負載均衡，容錯率提高知残；

• 不同的項目可采用不同的技術(shù)靠瞎；

• 系統(tǒng)間相互獨立。

缺點

• 系統(tǒng)之間相互調(diào)用求妹，如果某個系統(tǒng)的端口或者 IP 地址發(fā)生改變乏盐，調(diào)用系統(tǒng)需要手動變更；
• 垂直架構(gòu)中相同邏輯代碼需要不斷的復(fù)制制恍，不能復(fù)用父能。
• 系統(tǒng)性能擴展只能通過擴展集群結(jié)點，成本高净神、有瓶頸何吝。

SOA 面向服務(wù)架構(gòu)

當垂直應(yīng)用越來越多，應(yīng)用之間交互不可避免鹃唯，將核心業(yè)務(wù)抽取出來爱榕，作為獨立的服務(wù)，逐漸形成穩(wěn)定的服務(wù)中心坡慌。當服務(wù)越來越多呆细，容量的評估，小服務(wù)資源的浪費等問題逐漸顯現(xiàn)八匠，此時需增加一個調(diào)度中心基于訪問壓力實時管理集群容量絮爷，提高集群利用率。

P.S. 從軟件設(shè)計的角度上來說梨树，ESB 是一個抽象的間接層坑夯，提取了服務(wù)調(diào)用過程中調(diào)用與被調(diào)用動態(tài)交互中的一些共同的東西，減輕了服務(wù)調(diào)用者的負擔(dān)抡四。Java 編程思想里提到：“所有的軟件設(shè)計的問題都可以通過增加一個抽象的間接層而得到解決或者得到簡化柜蜈！”簡單來說 ESB 就是一根管道，用來連接各個服務(wù)節(jié)點指巡。為了集成不同系統(tǒng)淑履，不同協(xié)議的服務(wù)，ESB 做了消息的轉(zhuǎn)化解釋和路由工作藻雪，讓不同的服務(wù)互聯(lián)互通秘噪。

特點

• 基于 SOA 的架構(gòu)思想將重復(fù)公用的功能抽取為組件，以服務(wù)的形式給各系統(tǒng)提供服務(wù)勉耀。
• 各項目（系統(tǒng)）與服務(wù)之間采用 WebService指煎、RPC 等方式進行通信。
• 使用 ESB 企業(yè)服務(wù)總線作為項目與服務(wù)之間通信的橋梁便斥。

優(yōu)點

• 將重復(fù)的功能抽取為服務(wù)至壤，提高開發(fā)效率，提高系統(tǒng)的可重用性枢纠、可維護性像街。
• 可以針對不同服務(wù)的特點制定集群及優(yōu)化方案；
• 采用 ESB 減少系統(tǒng)中的接口耦合晋渺。

缺點

• 系統(tǒng)與服務(wù)的界限模糊镰绎，不利于開發(fā)及維護。
• 雖然使用了 ESB些举，但是服務(wù)的接口協(xié)議不固定跟狱，種類繁多，不利于系統(tǒng)維護户魏。
• 抽取的服務(wù)的粒度過大驶臊，系統(tǒng)與服務(wù)之間耦合性高。
• 涉及多種中間件叼丑，對開發(fā)人員技術(shù)棧要求高关翎。
• 服務(wù)關(guān)系復(fù)雜，運維鸠信、測試部署困難

微服務(wù)架構(gòu)

特點

• 將系統(tǒng)服務(wù)層完全獨立出來纵寝，并將服務(wù)層抽取為一個一個的微服務(wù)。
• 微服務(wù)中每一個服務(wù)都對應(yīng)唯一的業(yè)務(wù)能力星立，遵循單一原則爽茴。
• 微服務(wù)之間采用 RESTful 等輕量協(xié)議傳輸葬凳。

優(yōu)點

• 團隊獨立：每個服務(wù)都是一個獨立的開發(fā)團隊，這個小團隊可以是 2 到 5 人的開發(fā)人員組成室奏；
• 技術(shù)獨立：采用去中心化思想火焰，服務(wù)之間采用 RESTful 等輕量協(xié)議通信，使用什么技術(shù)什么語言開發(fā)胧沫，別人無需干涉昌简；
• 前后端分離：采用前后端分離開發(fā)，提供統(tǒng)一 Rest 接口绒怨，后端不用再為 PC纯赎、移動端開發(fā)不同接口；
• 數(shù)據(jù)庫分離：每個微服務(wù)都有自己的存儲能力南蹂，可以有自己的數(shù)據(jù)庫犬金。也可以有統(tǒng)一數(shù)據(jù)庫；
• 服務(wù)拆分粒度更細碎紊，有利于資源重復(fù)利用佑附，提高開發(fā)效率；
• 一個團隊的新成員能夠更快投入生產(chǎn)仗考；
• 微服務(wù)易于被一個開發(fā)人員理解音同，修改和維護，這樣小團隊能夠更關(guān)注自己的工作成果秃嗜。無需通過合作才能體現(xiàn)價值权均；
• 可以更加精準的制定每個服務(wù)的優(yōu)化方案（比如擴展），提高系統(tǒng)可維護性锅锨；
• 適用于互聯(lián)網(wǎng)時代叽赊，產(chǎn)品迭代周期更短。

缺點

• 微服務(wù)過多必搞，服務(wù)治理成本高必指，不利于系統(tǒng)維護；
• 分布式系統(tǒng)開發(fā)的技術(shù)成本高（網(wǎng)絡(luò)問題恕洲、容錯問題塔橡、調(diào)用關(guān)系、分布式事務(wù)等）霜第，對團隊挑戰(zhàn)大葛家；
• 微服務(wù)將原來的函數(shù)式調(diào)用改為服務(wù)調(diào)用，不管是用 rpc泌类，還是 http rest 方式癞谒，都會增大系統(tǒng)整體延遲。這個是再所難免的，這個就需要我們將原來的串行編程改為并發(fā)編程甚至異步編程弹砚，增加了技術(shù)門檻双仍；
• 多服務(wù)運維難度，隨著服務(wù)的增加迅栅，運維的壓力也在增大殊校；
• 測試的難度提升司光。服務(wù)和服務(wù)之間通過接口來交互臀防，當接口有改變的時候洼哎，對所有的調(diào)用方都是有影響的，這時自動化測試就顯得非常重要了让簿，如果要靠人工一個個接口去測試，那工作量就太大了秀睛，所以 API 文檔的管理尤為重要尔当。

總結(jié)

分享兩個小故事，幫助大家更好的理解 SOA 與微服務(wù)的區(qū)別蹂安。

故事一：

很久以前的一天椭迎，Martin 在跟好友的交流中悟到了一種很棒的架構(gòu)設(shè)計。他總結(jié)了一下田盈，然后告訴了好友畜号，好友說，這不是新鮮東西允瞧，早有人總結(jié)了简软，叫做 SOA。

Martin 很高興述暂，開始在公司內(nèi)外推廣 SOA痹升。結(jié)果，不停有人質(zhì)疑和挑戰(zhàn)他畦韭。

你這不是 SOA 吧疼蛾？SOA 這里應(yīng)該是如此這般的。對艺配，這里我對 SOA 的理解是這樣的察郁。你看，這本 SOA 的書說的和你說的有出入妒挎。粒度绳锅？SOA 沒有談到這個呀，你這不是 SOA酝掩。分層跟 SOA 沒有關(guān)系鳞芙，你為什么要說這個呢？…

Martin 沒辦法，心一橫原朝，老子就叫它 Martin's SOA驯嘱。老子發(fā)明的詞，老子就是最高權(quán)威喳坠，有最終解釋權(quán)鞠评。還有誰不服？

同事們一看壕鹉，這思想本身很不錯剃幌，值得推廣，但叫 Martin's SOA 太沒品了吧晾浴？還是要取個好一點的名字负乡，最好還能跟 SOA 有某種暗示傳承。干脆就叫 Microservices 好了脊凰，又新抖棘，又有服務(wù)含在其中。

Martin 忿忿地接受了這個建議狸涌，心里想著：娘的切省，明明就是 SOA，一群**非要逼我取個新名字帕胆。

后來 Martin 發(fā)現(xiàn)每次提一個東西就會收到舊惡傻勢力對解釋權(quán)的挑戰(zhàn)朝捆，所以每次要提一個什么概念，都去發(fā)明一個新詞惶楼，免得一群人在那一邊質(zhì)疑挑戰(zhàn)右蹦，一邊大談“我的理解”。

這就是微服務(wù)歼捐、敏捷何陆、精益企業(yè)、持續(xù)集成豹储、持續(xù)交付背后的故事贷盲。

一個名詞產(chǎn)生之后，命名者的解釋權(quán)就會隨著時間而弱化（比如 Cooper 發(fā)明的 Persona 就被無數(shù)設(shè)計師亂用）剥扣。敏捷已經(jīng)有點爛了巩剖，等微服務(wù)也爛了，我們還會發(fā)明新詞钠怯。

實在沒轍佳魔，都是被逼的啊。

故事二：

話說1979年晦炊，又是一個春天鞠鲜，莆田鄉(xiāng)下的赤腳醫(yī)生吳大牛被改革的春風(fēng)吹的心潮澎湃宁脊，說干就干，吳大牛趁著夜色朦朧找大隊支書匯報了匯報思想贤姆，第二天就承包了村衛(wèi)生室榆苞，開啟了自己的在醫(yī)療圈的傳奇歷程。

鄉(xiāng)村診所大家都知道霞捡，沒什么復(fù)雜的東東坐漏，房子只有一間，一個大柜臺中間隔開碧信，一半是診療兼候診區(qū)赊琳，一半是藥房，看病就直接找醫(yī)生音婶，如果前面有人就自己找個位子坐下慨畸，排隊等一會，秩序倒也井然衣式，看完病了醫(yī)生直接給抓藥，然后下一個繼續(xù)檐什，也不需要護士和藥劑師碴卧，吳大牛一個人全部包辦。

辛辛苦苦忙碌了十年乃正，時間來到了八九年住册，又是一個春天，昔日的單身漢吳大牛已成為十里八鄉(xiāng)的知名人物瓮具，媳婦娶上了不說荧飞，家里還增加了一對雙胞胎兒子，二層的小洋房也甚是氣派名党√纠可是也有煩心事，盡管鄉(xiāng)村診所擴大到了兩間传睹，媳婦還偶爾能去幫幫忙耳幢，但是醫(yī)生還是只有自己一個，天天從早忙到晚掙的都是一份錢欧啤，想多掙點怎么辦睛藻？吳大牛日思夜想，還真給他想出來一招邢隧，怎么辦店印，擴大規(guī)模，多招幾個醫(yī)生一起干倒慧。原來吳大牛只能治頭疼腦熱和跌打損傷按摘，現(xiàn)在新招了一個醫(yī)科大學(xué)的畢業(yè)生劉小明專治感冒發(fā)燒包券，又從鄰村請來了老大夫李阿花專治婦科病，現(xiàn)在一個普通的小診所就變成了有三個獨立科室加一個公共藥房（吳大牛媳婦負責(zé)）的小醫(yī)院了院峡，吳大牛是外科主任兼院長兴使，收入那可比之前翻了三番。人逢喜事精神爽照激，大牛院長請縣里的書法名家為新醫(yī)院書寫了牌匾--“博愛醫(yī)院”发魄，挑了一個黃道吉日正式掛了上去。

一晃十年過去了俩垃，又是一個春天励幼，吳大牛的博愛醫(yī)院已經(jīng)發(fā)展到了內(nèi)科外科婦科五官科骨科生殖科六個科室，每個科室3到5名醫(yī)生不等口柳，也耗費巨資購進了血液化驗B超等先進儀器苹粟，大牛院長也早已脫離了醫(yī)療一線，成為了專職的管理者跃闹，但是醫(yī)院的大事小事大家都找他嵌削，就這三十多號員工搞的他每天是焦頭爛額，想再擴大規(guī)模實在是有心無力了望艺。要說還是大學(xué)生有水平苛秕，老部下劉小明給大牛院長獻了一計，把各個科室獨立出去找默，讓各個科室主任自己管理艇劫，大牛院長只管科室之間的協(xié)調(diào)和醫(yī)院發(fā)展的大事，這樣既能調(diào)動基層的積極性惩激，又能把大牛院長解放出來擴大生產(chǎn)抓大事謀大事店煞，豈不妙哉？就這樣风钻，博愛醫(yī)院的新一輪改革轟轟烈烈的展開了顷蟀。

又是一個十年，又是一個春天魄咕，大牛院長已成為本地知名的企業(yè)家衩椒，博愛醫(yī)院也發(fā)展到了二十三個科室數(shù)百名員工，發(fā)展中也出現(xiàn)了新問題哮兰，由于各個科室獨立掛號毛萌、收費、化驗喝滞，有的科室整天忙忙碌碌效益好阁将，有的科室就相對平庸些，連分到的各種檢查儀器都不能滿負荷運行右遭，整個醫(yī)院養(yǎng)了不少閑人做盅。這時候大牛院長視野也開闊了缤削，請來了管理專家進行了頂層設(shè)計，把原來分散到各個科室的非核心服務(wù)全部收歸集中管理吹榴，把原來二十三個掛號窗口整合為十個亭敢，二十三個收費窗口整合為八個，集中布設(shè)在一樓大廳為全院服務(wù)图筹，還把分散在各個科室的檢查儀器集中起來成立獨立的檢驗科帅刀，也為全院服務(wù)，這樣人人有活干远剩，整個醫(yī)院的服務(wù)能力又上了一個新臺階扣溺，這輪改革后博愛醫(yī)院通過了各級部門的鑒定成為了遠近馳名的三甲醫(yī)院，吳大牛也搖身一變成為了博愛集團的CEO兼董事長瓜晤，下一步就準備IPO上市了锥余。

說到這里大家可能有點糊涂，這個跟微服務(wù)有嘛關(guān)系痢掠？大牛診所的1.0階段就相當于軟件開發(fā)的單體結(jié)構(gòu)驱犹，一個程序員打天下，從頭編到尾足画，很難做大做強着绷。大牛診所的2.0階段就相當于軟件開發(fā)的垂直結(jié)構(gòu)，各科室按照業(yè)務(wù)劃分锌云，很容易橫向擴展。博愛醫(yī)院的1.0階段就相當于軟件開發(fā)的SOA結(jié)構(gòu)吁脱，除了藥房（數(shù)據(jù)庫）外各個服務(wù)獨立提供（科室主任負責(zé)）桑涎，但需要大牛院長（ESB總線）來協(xié)調(diào)。博愛醫(yī)院的2.0階段就相當于軟件開發(fā)的微服務(wù)結(jié)構(gòu)兼贡，公共服務(wù)院內(nèi)共享攻冷，科室主任管理功能弱化（只管醫(yī)生業(yè)務(wù)），優(yōu)點是擴容方便遍希，哪個部門缺人直接加等曼，不用看上下游，資源利用率高凿蒜，人員和設(shè)備效率高禁谦。

微服務(wù)就是將一個單體架構(gòu)的應(yīng)用按業(yè)務(wù)劃分為一個個的獨立運行的程序即服務(wù)，它們之間通過 HTTP 協(xié)議進行通信（也可以采用消息隊列來通信废封，如 RabbitMQ州泊，Kafaka 等），可以采用不同的編程語言漂洋，使用不同的存儲技術(shù)遥皂，自動化部署（如 Jenkins）減少人為控制力喷，降低出錯概率。服務(wù)數(shù)量越多演训，管理起來越復(fù)雜岛抄，因此采用集中化管理龄糊。例如 Eureka，Zookeeper 等都是比較常見的服務(wù)集中化管理框架。

微服務(wù)是一種架構(gòu)風(fēng)格羽莺，架構(gòu)就是為了解耦，實際使用的是分布式系統(tǒng)開發(fā)驶鹉。一個大型的復(fù)雜軟件應(yīng)用轰驳，由一個或多個微服務(wù)組成。系統(tǒng)中的各個微服務(wù)可被獨立部署礁苗，各個微服務(wù)之間是松耦合的爬凑。每個微服務(wù)僅關(guān)注于完成一件任務(wù)并很好的完成該任務(wù)。

一句話總結(jié)：微服務(wù)是 SOA 發(fā)展出來的產(chǎn)物试伙，它是一種比較現(xiàn)代化的細粒度的 SOA 實現(xiàn)方式嘁信。

微服務(wù)設(shè)計原則

AKF 拆分原則

業(yè)界對于可擴展的系統(tǒng)架構(gòu)設(shè)計有一個樸素的理念，就是：通過加機器可以解決容量和可用性問題（如果一臺不行就兩臺）疏叨。

用個段子描述就是：世界上沒有什么事是一頓燒烤解決不了的潘靖，如果有，那就兩頓蚤蔓。

《The Art of Scalability》一書提出了一個系統(tǒng)的可擴展模型——AKF 可擴展立方卦溢。這個立方體中沿著三個坐標軸設(shè)置分別為 X，Y秀又，Z单寂。

一個叫 AKF 的公司的技術(shù)專家抽象總結(jié)的應(yīng)用擴展的三個維度。理論上按照這三個擴展模式吐辙，可以將一個單體系統(tǒng)宣决，進行無限擴展。

Y 軸

就是我們所說的微服務(wù)的拆分模式昏苏，就是基于不同的業(yè)務(wù)拆分尊沸。Y 軸擴展會將龐大的整體應(yīng)用拆分為多個服務(wù)。每個服務(wù)實現(xiàn)一組相關(guān)的功能贤惯，如商品管理洼专、訂單管理、用戶管理等救巷。

X 軸

X 軸擴展指得是水平復(fù)制壶熏，通過絕對平等地復(fù)制服務(wù)與數(shù)據(jù)，以解決容量和可用性的問題浦译。很好理解棒假，就是將單體系統(tǒng)多運行幾個實例溯职，成為集群加負載均衡的模式。

Z 軸

Z 軸擴展通常是指基于請求者或用戶獨特的需求帽哑，進行系統(tǒng)劃分谜酒，并使得劃分出來的子系統(tǒng)是相互隔離但又是完整的。以生產(chǎn)手機的工廠來舉例：蘋果公司為了發(fā)展在中國的業(yè)務(wù)妻枕，或者利用中國的廉價勞動力僻族，在中國建立一個完整的子工廠，與美國工廠一樣屡谐，負責(zé)完整的手機生產(chǎn)述么。這就是一種 Z 軸擴展。

場景說明：比如單體打車應(yīng)用愕掏，一個集群撐不住時度秘，分了多個集群，后來用戶激增還是不夠用饵撑，經(jīng)過分析發(fā)現(xiàn)是乘客和車主訪問量很大剑梳，就將打車應(yīng)用拆成了三個，分別為乘客服務(wù)滑潘、車主服務(wù)垢乙、支付服務(wù)。三個服務(wù)的業(yè)務(wù)特點各不相同语卤，獨立維護追逮，各自都可以再次按需擴展。我們可以水平擴展三個服務(wù)粹舵，形成各自服務(wù)的集群模式羊壹。實在不行最后根據(jù)北上廣熱門地區(qū)劃分為多份，你在哪個城市打車齐婴，就給你展示哪個城市的司機數(shù)據(jù)分區(qū)。

前后端分離原則

以前的 Java Web 項目大多都是程序員既當?shù)之攱尦砻雀闱岸四迹指愫蠖恕ｋS著時代的發(fā)展睬关，漸漸的許多大中小公司開始把前后端的界限分的越來越明確诱担，前端工程師只管前端的事情，后端工程師只管后端的事情电爹。正所謂術(shù)業(yè)有專攻蔫仙，大中型公司需要專業(yè)人才，小公司需要全才丐箩，但是對于個人職業(yè)發(fā)展來說摇邦，前后端需要分離恤煞，畢竟一個人如果什么都會，那么他可能什么都不精施籍。

未分離

在前后端不分離的應(yīng)用模式中居扒，前端頁面看到的效果都是由后端控制，由后端渲染頁面或重定向丑慎，也就是后端需要控制前端的展示喜喂，前端與后端的耦合度很高。

這種應(yīng)用模式比較適合純網(wǎng)頁應(yīng)用竿裂，但是當后端對接 App 時玉吁，App 可能并不需要后端返回一個 HTML 網(wǎng)頁，而僅僅是數(shù)據(jù)本身腻异，所以后端原本返回網(wǎng)頁的接口不再適用于前端 App 應(yīng)用进副，為了對接 App 后端還需再開發(fā)一套接口。

該時期代表：Servlet + Jsp + JavaBean

<body>
   <%
       request.setCharacterEncoding("utf-8");
       String username = request.getParameter("username");
       System.out.print(username);
   %>
</body>

半分離

前后端半分離捂掰，前端負責(zé)開發(fā)頁面敢会，通過接口（Ajax）獲取數(shù)據(jù)，采用 Dom 操作對頁面進行數(shù)據(jù)綁定这嚣，最終是由前端把頁面渲染出來鸥昏。步驟如下：

1. 打開 WEB，加載基本資源姐帚，如 CSS吏垮，JS 等；
2. 發(fā)起一個 Ajax 請求再到服務(wù)端請求數(shù)據(jù)罐旗，同時展示 Loading膳汪；
3. 得到 Json 格式的數(shù)據(jù)后再根據(jù)邏輯選擇模板渲染出 DOM 字符串；
4. 將 DOM 字符串插入頁面中渲染出 DOM 結(jié)構(gòu)九秀；

然而遗嗽，在這種架構(gòu)下，還是存在明顯的弊端的鼓蜒。最明顯的有如下幾點：

1. JS 存在大量冗余痹换，在業(yè)務(wù)復(fù)雜的情況下，頁面的渲染部分的代碼都弹，非常復(fù)雜娇豫；
2. 在 Json 返回的數(shù)據(jù)量比較大的情況下，渲染的十分緩慢畅厢，會出現(xiàn)頁面卡頓的情況冯痢；
3. 資源消耗嚴重，在業(yè)務(wù)復(fù)雜的情況下，一個頁面可能要發(fā)起多次 HTTP 請求才能將頁面渲染完畢浦楣。PC 端建立多次 HTTP 請求也沒啥袖肥。這里需要考慮一下移動端的感受。

該時期代表：SSM（Spring + SpringMVC + Mybatis）和 SSH（Spring + Struts2 + Hibernate）

分離

在前后端分離的應(yīng)用模式中椒振，后端僅返回前端所需的數(shù)據(jù)昭伸，不再渲染 HTML 頁面，不再控制前端的效果澎迎。至于前端用戶看到什么效果庐杨，從后端請求的數(shù)據(jù)如何加載到前端中，都由前端自己決定夹供，網(wǎng)頁有網(wǎng)頁的處理方式灵份，App 有 App 的處理方式，但無論哪種前端哮洽，所需的數(shù)據(jù)基本相同填渠，后端僅需開發(fā)一套邏輯對外提供數(shù)據(jù)即可。

瀏覽器不再直接請求 JSP 的 API鸟辅，而是：

1. 瀏覽器請求服務(wù)器端的 NodeJS氛什；
2. NodeJS 再發(fā)起 HTTP 去請求后端；
3. 后端依然原樣 API 輸出 JSON 給 NodeJS匪凉；
4. NodeJS 收到 JSON 后再渲染出 HTML 頁面枪眉；
5. NodeJS 直接將 HTML 頁面 flush 到瀏覽器；

這樣再层，瀏覽器得到的就是普通的 HTML 頁面贸铜，而不用再發(fā) Ajax 去請求服務(wù)器了。

該時期代表：VueJS聂受、AngularJS蒿秦、ReactJS

總結(jié)

從經(jīng)典的 Servlet + Jsp + JavaBean 的 MVC 時代，到 SSM（Spring + SpringMVC + Mybatis）和 SSH（Spring + Struts2 + Hibernate）的 Java 框架時代蛋济，再到前端框架（VueJS棍鳖、AngularJS、ReactJS）為主的 MVVM 時代碗旅，然后是 Nodejs 引領(lǐng)的全棧時代鹊杖，技術(shù)和架構(gòu)一直都在進步。創(chuàng)新之路不會止步扛芽，無論是前后端分離模式還是其他模式，都是為了更方便地解決需求积瞒，但它們都只是一個“中轉(zhuǎn)站”川尖。前端項目與后端項目是兩個項目，放在兩個不同的服務(wù)器，需要獨立部署叮喳，兩個不同的工程被芳，兩個不同的代碼庫，不同的開發(fā)人員馍悟。前端只需要關(guān)注頁面的樣式與動態(tài)數(shù)據(jù)的解析及渲染畔濒，而后端專注于具體業(yè)務(wù)邏輯。

• 前后端技術(shù)分離锣咒，可以由各自的專家來對各自的領(lǐng)域進行優(yōu)化侵状，這樣前端的用戶體驗優(yōu)化效果更好。
• 前后端分離模式下毅整，前后端交互界面更清晰趣兄，就剩下了接口模型，后端的接口簡潔明了悼嫉，更容易維護艇潭。
• 前端多渠道集成場景更容易實現(xiàn)，后端服務(wù)無需變更戏蔑，采用統(tǒng)一的數(shù)據(jù)和模型蹋凝，可以支持多個前端：例如：微信 h5 前端、PC 前端总棵、安卓前端鳍寂、IOS 前端。

無狀態(tài)服務(wù)

對于無狀態(tài)服務(wù)彻舰，首先說一下什么是狀態(tài)：如果一個數(shù)據(jù)需要被多個服務(wù)共享伐割，才能完成一筆交易，那么這個數(shù)據(jù)被稱為狀態(tài)刃唤。進而依賴這個“狀態(tài)”數(shù)據(jù)的服務(wù)被稱為有狀態(tài)服務(wù)隔心，反之稱為無狀態(tài)服務(wù)。

這個無狀態(tài)服務(wù)原則并不是說在微服務(wù)架構(gòu)里就不允許存在狀態(tài)尚胞，表達的真實意思是要把有狀態(tài)的業(yè)務(wù)服務(wù)改變?yōu)闊o狀態(tài)的計算類服務(wù)硬霍，那么狀態(tài)數(shù)據(jù)也就相應(yīng)的遷移到對應(yīng)的“有狀態(tài)數(shù)據(jù)服務(wù)”中。

場景說明：例如我們以前在本地內(nèi)存中建立的數(shù)據(jù)緩存笼裳、Session 緩存唯卖，到現(xiàn)在的微服務(wù)架構(gòu)中就應(yīng)該把這些數(shù)據(jù)遷移到分布式緩存中存儲，讓業(yè)務(wù)服務(wù)變成一個無狀態(tài)的計算節(jié)點躬柬。遷移后拜轨，就可以做到按需動態(tài)伸縮，微服務(wù)應(yīng)用在運行時動態(tài)增刪節(jié)點允青，就不再需要考慮緩存數(shù)據(jù)如何同步的問題橄碾。

也就是對同一個 url 請求沒有上下文關(guān)系。舉個生活中的例子：

比如空調(diào)遙控器，你按上下調(diào)整溫度時法牲，空調(diào)溫度設(shè)定值會變化史汗，遙控器信號到空調(diào)是單向傳輸。現(xiàn)在空調(diào)顯示溫度 20 度拒垃，遙控器 20 度停撞。如果遙控器與空調(diào)之間是有狀態(tài)的，假設(shè)你離開空調(diào)接收范圍調(diào)整了遙控器溫度悼瓮，變成 19戈毒，那回到范圍內(nèi)你按一次升高一度，基于原先溫度狀態(tài)谤牡，遙控器給空調(diào)發(fā)送一個“提高1度”的指令氛悬，就會出現(xiàn)遙控器提高到 20葫男，而空調(diào)變成21掏婶。如果要空間與空調(diào)之前是無狀態(tài)的亏镰，假設(shè)你離開空調(diào)接收范圍調(diào)整了遙控器溫度，變成 19套么，那回到范圍內(nèi)你按一次升高一度培己，遙控器給空調(diào)發(fā)送一個“設(shè)定溫度值20”，這樣兩者最終還是相同的值胚泌。

Restful 通信風(fēng)格

基于“無狀態(tài)通信原則”省咨，在這里我們直接推薦一個實踐優(yōu)選的 Restful 通信風(fēng)格 ，因為他有很多好處：

• 無狀態(tài)協(xié)議 HTTP玷室，具備先天優(yōu)勢零蓉，擴展能力很強。例如需要安全加密時穷缤，有現(xiàn)成的成熟方案 HTTPS 可用敌蜂。
• JSON 報文序列化，輕量簡單津肛，人與機器均可讀章喉，學(xué)習(xí)成本低，搜索引擎友好身坐。
• 語言無關(guān)秸脱，各大熱門語言都提供成熟的 Restful API 框架，相對其他的一些 RPC 框架生態(tài)更完善部蛇。

CAP 原則與 BASE 理論

CAP 原則

CAP 原則又稱 CAP 定理摊唇，指的是在一個分布式系統(tǒng)中， Consistency（一致性）涯鲁、 Availability（可用性）巷查、Partition tolerance（分區(qū)容錯性）嘹害，三者不可得兼。

CAP 由 Eric Brewer 在 2000 年 PODC 會議上提出吮便。該猜想在提出兩年后被證明成立，成為我們熟知的 CAP 定理幢踏。CAP 三者不可兼得髓需。

取舍策略

CAP 三個特性只能滿足其中兩個水醋，那么取舍的策略就共有三種：

• CA without P：如果不要求P（不允許分區(qū)），則C（強一致性）和A（可用性）是可以保證的彪置。但放棄 P 的同時也就意味著放棄了系統(tǒng)的擴展性拄踪，也就是分布式節(jié)點受限，沒辦法部署子節(jié)點悉稠，這是違背分布式系統(tǒng)設(shè)計的初衷的宫蛆。
• CP without A：如果不要求A（可用），相當于每個請求都需要在服務(wù)器之間保持強一致的猛，而P（分區(qū)）會導(dǎo)致同步時間無限延長（也就是等待數(shù)據(jù)同步完才能正常訪問服務(wù)）耀盗，一旦發(fā)生網(wǎng)絡(luò)故障或者消息丟失等情況，就要犧牲用戶的體驗卦尊，等待所有數(shù)據(jù)全部一致了之后再讓用戶訪問系統(tǒng)叛拷。設(shè)計成 CP 的系統(tǒng)其實不少，最典型的就是分布式數(shù)據(jù)庫岂却，如 Redis忿薇、HBase 等裙椭。對于這些分布式數(shù)據(jù)庫來說，數(shù)據(jù)的一致性是最基本的要求署浩，因為如果連這個標準都達不到揉燃，那么直接采用關(guān)系型數(shù)據(jù)庫就好，沒必要再浪費資源來部署分布式數(shù)據(jù)庫筋栋。
• AP without C：要高可用并允許分區(qū)炊汤，則需放棄一致性。一旦分區(qū)發(fā)生弊攘，節(jié)點之間可能會失去聯(lián)系抢腐，為了高可用，每個節(jié)點只能用本地數(shù)據(jù)提供服務(wù)襟交，而這樣會導(dǎo)致全局數(shù)據(jù)的不一致性迈倍。典型的應(yīng)用就如某米的搶購手機場景，可能前幾秒你瀏覽商品的時候頁面提示是有庫存的捣域，當你選擇完商品準備下單的時候啼染，系統(tǒng)提示你下單失敗，商品已售完竟宋。這其實就是先在 A（可用性）方面保證系統(tǒng)可以正常的服務(wù)提完，然后在數(shù)據(jù)的一致性方面做了些犧牲，雖然多少會影響一些用戶體驗丘侠，但也不至于造成用戶購物流程的嚴重阻塞徒欣。

總結(jié)

現(xiàn)如今，對于多數(shù)大型互聯(lián)網(wǎng)應(yīng)用的場景蜗字，主機眾多打肝、部署分散，而且現(xiàn)在的集群規(guī)模越來越大挪捕，節(jié)點只會越來越多粗梭，所以節(jié)點故障、網(wǎng)絡(luò)故障是常態(tài)级零，因此分區(qū)容錯性也就成為了一個分布式系統(tǒng)必然要面對的問題断医。那么就只能在 C 和 A 之間進行取舍。但對于傳統(tǒng)的項目就可能有所不同奏纪，拿銀行的轉(zhuǎn)賬系統(tǒng)來說鉴嗤，涉及到金錢的對于數(shù)據(jù)一致性不能做出一絲的讓步，C 必須保證序调，出現(xiàn)網(wǎng)絡(luò)故障的話醉锅，寧可停止服務(wù)，可以在 A 和 P 之間做取舍发绢。而互聯(lián)網(wǎng)非金融項目普遍都是基于 AP 模式硬耍。

總而言之垄琐，沒有最好的策略，好的系統(tǒng)應(yīng)該是根據(jù)業(yè)務(wù)場景來進行架構(gòu)設(shè)計的经柴，只有適合的才是最好的狸窘。

BASE 理論

CAP 理論已經(jīng)提出好多年了，難道真的沒有辦法解決這個問題嗎坯认？也許可以做些改變朦前。比如 C 不必使用那么強的一致性，可以先將數(shù)據(jù)存起來鹃操，稍后再更新，實現(xiàn)所謂的 “最終一致性”春哨。

這個思路又是一個龐大的問題荆隘，同時也引出了第二個理論 BASE 理論。

BASE：全稱 Basically Available（基本可用）赴背，Soft state（軟狀態(tài)）椰拒，和 Eventually consistent（最終一致性）三個短語的縮寫，來自 ebay 的架構(gòu)師提出凰荚。

BASE 理論是對 CAP 中一致性和可用性權(quán)衡的結(jié)果燃观，其來源于對大型互聯(lián)網(wǎng)分布式實踐的總結(jié)，是基于 CAP 定理逐步演化而來的便瑟。其核心思想是：

既然無法做到強一致性（Strong consistency）缆毁，但每個應(yīng)用都可以根據(jù)自身的業(yè)務(wù)特點，采用適當?shù)姆绞絹硎瓜到y(tǒng)達到最終一致性（Eventual consistency）到涂。

Basically Available（基本可用）

基本可用是指分布式系統(tǒng)在出現(xiàn)故障的時候脊框，允許損失部分可用性（例如響應(yīng)時間、功能上的可用性）践啄。需要注意的是浇雹，基本可用絕不等價于系統(tǒng)不可用。

• 響應(yīng)時間上的損失：正常情況下搜索引擎需要在 0.5 秒之內(nèi)返回給用戶相應(yīng)的查詢結(jié)果屿讽，但由于出現(xiàn)故障（比如系統(tǒng)部分機房發(fā)生斷電或斷網(wǎng)故障）昭灵，查詢結(jié)果的響應(yīng)時間增加到了 1~2 秒。
• 功能上的損失：購物網(wǎng)站在購物高峰（如雙十一）時伐谈，為了保護系統(tǒng)的穩(wěn)定性烂完，部分消費者可能會被引導(dǎo)到一個降級頁面。

Soft state（軟狀態(tài)）

什么是軟狀態(tài)呢衩婚？相對于原子性而言窜护，要求多個節(jié)點的數(shù)據(jù)副本都是一致的，這是一種 “硬狀態(tài)”非春。

軟狀態(tài)是指允許系統(tǒng)存在中間狀態(tài)柱徙，而該中間狀態(tài)不會影響系統(tǒng)整體可用性缓屠。分布式存儲中一般一份數(shù)據(jù)會有多個副本，允許不同副本數(shù)據(jù)同步的延時就是軟狀態(tài)的體現(xiàn)护侮。

Eventually consistent（最終一致性）

系統(tǒng)不可能一直是軟狀態(tài)敌完，必須有個時間期限。在期限過后羊初，應(yīng)當保證所有副本保持數(shù)據(jù)一致性滨溉。從而達到數(shù)據(jù)的最終一致性。這個時間期限取決于網(wǎng)絡(luò)延時长赞，系統(tǒng)負載晦攒，數(shù)據(jù)復(fù)制方案設(shè)計等等因素。

實際上得哆，不只是分布式系統(tǒng)使用最終一致性脯颜，關(guān)系型數(shù)據(jù)庫在某個功能上，也是使用最終一致性的贩据，比如備份栋操，數(shù)據(jù)庫的復(fù)制都是需要時間的，這個復(fù)制過程中饱亮，業(yè)務(wù)讀取到的值就是舊值矾芙。當然，最終還是達成了數(shù)據(jù)一致性近上。這也算是一個最終一致性的經(jīng)典案例剔宪。

總結(jié)

總的來說，BASE 理論面向的是大型高可用可擴展的分布式系統(tǒng)壹无，和傳統(tǒng)事務(wù)的 ACID 是相反的歼跟，它完全不同于 ACID 的強一致性模型，而是通過犧牲強一致性來獲得可用性格遭，并允許數(shù)據(jù)在一段時間是不一致的哈街。

微服務(wù)架構(gòu)帶來的問題

客戶端如何訪問服務(wù)？

傳統(tǒng)的開發(fā)方式拒迅，所有的服務(wù)都是本地的骚秦，客戶端可以直接調(diào)用，現(xiàn)在按功能拆分成獨立的服務(wù)璧微，客戶端如何訪問作箍？

后臺有 N 個服務(wù)，前臺就需要管理 N 個服務(wù)前硫，一個服務(wù)下線/更新/升級胞得，前臺就要重新部署，這明顯不符合我們拆分的理念屹电，另外阶剑，N 個服務(wù)的調(diào)用也是一個不小的網(wǎng)絡(luò)開銷跃巡。還有一般微服務(wù)在系統(tǒng)內(nèi)部，通常是無狀態(tài)的牧愁，用戶登錄信息和權(quán)限管理最好有一個統(tǒng)一的地方維護管理（OAuth2）素邪。

所以，一般在后臺 N 個服務(wù)和客戶端之間一般會一個代理（API Gateway）猪半，作用如下：

• 提供統(tǒng)一服務(wù)入口兔朦，聚合接口使得服務(wù)對調(diào)用者透明，客戶端與后端的耦合度降低
• 聚合后臺服務(wù)磨确，節(jié)省流量沽甥，提高性能，提升用戶體驗
• 提供安全乏奥、流控安接、過濾、緩存英融、計費、監(jiān)控等 API 管理功能

服務(wù)之間如何通信歇式？

因為服務(wù)都是獨立部署的驶悟，所以通信也就成了問題，不過好在業(yè)界已經(jīng)有很多成熟的解決方案材失，比如：

• 同步通信：
  • REST（JAX-RS痕鳍，Spring Boot）
  • RPC（Dubbo，Thrift）
• 異步通信：
  • RabbitMQ龙巨，Kafka

這么多服務(wù)如何查找笼呆？

在微服務(wù)架構(gòu)中，為了高可用旨别，普遍采用集群方式構(gòu)建服務(wù)诗赌。一個服務(wù)可能隨時下線，也可能應(yīng)對臨時訪問壓力增加新的服務(wù)節(jié)點秸弛。

服務(wù)之間如何相互感知铭若？服務(wù)如何管理？這就是服務(wù)發(fā)現(xiàn)的問題了即供〉媸停基本都是通過類似 ZooKeeper 等類似技術(shù)做服務(wù)注冊信息的分布式管理弹澎。當服務(wù)上線時，服務(wù)提供者將自己的服務(wù)信息注冊到 ZooKeeper（或類似框架）镜雨，并通過心跳維持長連接，實時更新連接信息儿捧。服務(wù)調(diào)用者通過 ZooKeeper 尋址荚坞，找到一個服務(wù)挑宠，還可以將服務(wù)信息緩存在本地以提高性能。當服務(wù)下線時西剥，ZooKeeper 會發(fā)通知給服務(wù)客戶端痹栖。

服務(wù)掛了怎么辦？

在微服務(wù)架構(gòu)中瞭空，一個請求需要調(diào)用多個服務(wù)是非常常見的揪阿。如客戶端訪問 A 服務(wù)，而 A 服務(wù)需要調(diào)用 B 服務(wù)咆畏，B 服務(wù)需要調(diào)用 C 服務(wù)南捂，由于網(wǎng)絡(luò)原因或者自身的原因，如果 B 服務(wù)或者 C 服務(wù)不能及時響應(yīng)旧找，A 服務(wù)將處于阻塞狀態(tài)溺健，直到 B 服務(wù) C 服務(wù)響應(yīng)。此時若有大量的請求涌入钮蛛，容器的線程資源會被消耗完畢鞭缭，導(dǎo)致服務(wù)癱瘓。服務(wù)與服務(wù)之間的依賴性魏颓，故障會傳播岭辣，造成連鎖反應(yīng)，會對整個微服務(wù)系統(tǒng)造成災(zāi)難性的嚴重后果甸饱，這就是服務(wù)故障的“雪崩”效應(yīng)沦童。

雪崩是系統(tǒng)中的蝴蝶效應(yīng)導(dǎo)致，其發(fā)生的原因多種多樣叹话，從源頭我們無法完全杜絕雪崩的發(fā)生偷遗，但是雪崩的根本原因來源于服務(wù)之間的強依賴，所以我們可以提前評估做好服務(wù)容錯驼壶。解決方案大概可以分為以下幾種：

• 請求緩存：支持將一個請求與返回結(jié)果做緩存處理氏豌；
• 請求合并：將相同的請求進行合并然后調(diào)用批處理接口；
• 請求限流：當請求過多時热凹，可能會拖垮整個網(wǎng)站箩溃，通常會采取限流措施，降低機器的負載碌嘀；
• 服務(wù)隔離：限制調(diào)用分布式服務(wù)的資源涣旨，某一個調(diào)用的服務(wù)出現(xiàn)問題不會影響其他服務(wù)調(diào)用；
• 服務(wù)熔斷：犧牲局部服務(wù)股冗，保全整體系統(tǒng)穩(wěn)定性的措施霹陡；
• 服務(wù)降級：服務(wù)熔斷以后，客戶端調(diào)用自己本地方法返回缺省值。

微服務(wù)架構(gòu)生態(tài)體系

服務(wù)網(wǎng)關(guān)

隨著微服務(wù)的不斷增多烹棉，不同的微服務(wù)一般會有不同的網(wǎng)絡(luò)地址攒霹，而外部客戶端可能需要調(diào)用多個服務(wù)的接口才能完成一個業(yè)務(wù)需求，如果讓客戶端直接與各個微服務(wù)通信可能出現(xiàn)：

• 客戶端會多次請求不同的微服務(wù)浆洗，增加了客戶端的復(fù)雜性
• 存在跨域請求催束，在一定場景下處理相對復(fù)雜
• 身份認證問題，每個微服務(wù)需要獨立身份認證
• 難以重構(gòu)伏社，隨著項目的迭代抠刺，可能需要重新劃分微服務(wù)
• 某些微服務(wù)可能使用了防火墻/瀏覽器不友好的協(xié)議，直接訪問會有一定的困難

針對這些問題摘昌，API網(wǎng)關(guān)順勢而生速妖。

API 網(wǎng)關(guān)直面意思是將所有 API 調(diào)用統(tǒng)一接入到 API 網(wǎng)關(guān)層，由網(wǎng)關(guān)層統(tǒng)一接入和輸出聪黎。一個網(wǎng)關(guān)的基本功能有：統(tǒng)一接入罕容、安全防護、協(xié)議適配稿饰、流量管控锦秒、長短連接支持、容錯能力喉镰。有了網(wǎng)關(guān)之后旅择，各個 API 服務(wù)提供團隊可以專注于自己的的業(yè)務(wù)邏輯處理，而 API 網(wǎng)關(guān)更專注于安全梧喷、流量、路由等問題脖咐。

服務(wù)調(diào)用

在微服務(wù)架構(gòu)中铺敌，通常存在多個服務(wù)之間的遠程調(diào)用的需求。目前主流的遠程調(diào)用技術(shù)有基于 HTTP 的 RESTful 接口和基于 TCP 的 RPC 協(xié)議屁擅。以上兩種都屬于同步通信偿凭，還有基于隊列模式的異步通信。

• REST（Representational State Transfer）：一種 HTTP 調(diào)用的格式派歌，更標準弯囊，更通用，無論哪種語言都支持 http 協(xié)議胶果。
• RPC（Remote Promote Call）：一種進程間通信方式匾嘱，允許像調(diào)用本地服務(wù)一樣調(diào)用遠程服務(wù)。RPC 框架的主要目標就是讓遠程服務(wù)調(diào)用更簡單早抠、透明霎烙。RPC 框架負責(zé)屏蔽底層的傳輸方式、序列化方式和通信細節(jié)。開發(fā)人員在使用的時候只需要了解誰在什么位置提供了什么樣的遠程服務(wù)接口即可悬垃，并不需要關(guān)心底層通信細節(jié)和調(diào)用過程游昼。

服務(wù)治理

服務(wù)治理就是進行服務(wù)的自動化管理，其核心是服務(wù)的自動注冊與發(fā)現(xiàn)尝蠕。

• 服務(wù)注冊：服務(wù)實例將自身服務(wù)信息注冊到注冊中心烘豌。
• 服務(wù)發(fā)現(xiàn)：服務(wù)實例通過注冊中心，獲取注冊到其中的服務(wù)實例的信息看彼，通過這些信息去請求它們提供的服務(wù)廊佩。
• 服務(wù)剔除：服務(wù)注冊中心將出問題的服務(wù)自動剔除到可用列表之外，使其不會被調(diào)用到闲昭。

負載均衡

服務(wù)高可用的保證手段罐寨，為了保證高可用，每一個微服務(wù)都需要部署多個服務(wù)實例來提供服務(wù)序矩，此時就需要根據(jù)不同的負載均衡策略對服務(wù)進行調(diào)用鸯绿。

負載均衡策略

輪詢策略

實現(xiàn)原理：輪詢策略表示每次都順序取下一個 provider，比如一共有 5 個 provider簸淀，第 1 次取第 1 個瓶蝴，第 2 次取第 2 個，第 3 次取第 3 個租幕，以此類推舷手。

權(quán)重輪詢策略

實現(xiàn)原理：

• 根據(jù)每個 provider 的響應(yīng)時間分配一個權(quán)重，響應(yīng)時間越長劲绪，權(quán)重越小男窟，被選中的可能性越低。
• 原理：一開始為輪詢策略贾富，并開啟一個計時器歉眷，每 30 秒收集一次每個 provider 的平均響應(yīng)時間颤枪，當信息足夠時汗捡，給每個 provider 附上一個權(quán)重，并按權(quán)重隨機選擇 provider畏纲，高權(quán)越重的 provider 會被高概率選中扇住。

隨機策略

實現(xiàn)原理：從 provider 列表中隨機選擇一個。

最少并發(fā)數(shù)策略

實現(xiàn)原理：選擇正在請求中的并發(fā)數(shù)最小的 provider盗胀，除非這個 provider 在熔斷中艘蹋。

重試策略

實現(xiàn)原理：其實就是輪詢策略的增強版，輪詢策略服務(wù)不可用時不做處理票灰，重試策略服務(wù)不可用時會重新嘗試集群中的其他節(jié)點簿训。

可用性敏感策略

實現(xiàn)原理：過濾性能差的 provider

• 第一種：過濾掉在 Eureka 中處于一直連接失敗的 provider咱娶。
• 第二種：過濾掉高并發(fā)（繁忙）的 provider。

區(qū)域敏感性策略

實現(xiàn)原理：

• 以一個區(qū)域為單位考察可用性强品，對于不可用的區(qū)域整個丟棄膘侮，從剩下區(qū)域中選可用的 provider。
• 如果這個 ip 區(qū)域內(nèi)有一個或多個實例不可達或響應(yīng)變慢的榛，都會降低該 ip 區(qū)域內(nèi)其他 ip 被選中的權(quán)
  重琼了。

服務(wù)容錯

在微服務(wù)中，一個請求經(jīng)常會涉及到調(diào)用多個服務(wù)夫晌，如果其中某個服務(wù)不可用雕薪，沒有做服務(wù)容錯的話，極有可能會造成一連串的服務(wù)不可用晓淀，這就是雪崩效應(yīng)所袁。最終的結(jié)果就是：一個服務(wù)不可用，導(dǎo)致一系列服務(wù)的不可用凶掰。

造成雪崩的原因可以歸結(jié)為以下三點：

• 服務(wù)提供者不可用（硬件故障燥爷，程序 BUG，緩存擊穿懦窘，用戶大量請求等）
• 重試加大流量（用戶重試前翎，代碼邏輯重試）
• 服務(wù)消費者不可用（同步等待造成的資源耗盡）

我們沒法預(yù)防雪崩效應(yīng)的發(fā)生，只能盡可能去做好容錯畅涂。服務(wù)容錯的三個核心思想是：

• 不被外界環(huán)境影響
• 不被上游請求壓垮
• 不被下游響應(yīng)拖垮

鏈路追蹤

隨著微服務(wù)架構(gòu)的流行港华，服務(wù)按照不同的維度進行拆分，一次請求往往需要涉及到多個服務(wù)午衰×⒁耍互聯(lián)網(wǎng)應(yīng)用構(gòu)建在不同的軟件模塊集上，這些軟件模塊臊岸，有可能是由不同的團隊開發(fā)橙数、可能使用不同的編程語言來實現(xiàn)、有可能布在了幾千臺服務(wù)器扇单，橫跨多個不同的數(shù)據(jù)中心商模。因此奠旺，就需要對一次請求涉及的多個服務(wù)鏈路進行日志記錄蜘澜，性能監(jiān)控等等。單純的理解鏈路追蹤响疚，就是指一次任務(wù)的開始到結(jié)束鄙信，期間調(diào)用的所有系統(tǒng)及耗時（時間跨度）都可以完整記錄下來。

鏈路追蹤系統(tǒng)做好了忿晕，鏈路數(shù)據(jù)有了装诡，借助前端解析和渲染工具，可以達到下圖中的效果：

配置中心

配置文件是我們再熟悉不過的，在微服務(wù)系統(tǒng)中鸦采，每個微服務(wù)不僅僅只有代碼宾巍，還需要連接其他資源，例如數(shù)據(jù)庫的配置或功能性的開關(guān) MySQL渔伯、Redis 顶霞、Security 等相關(guān)的配置。除了項目運行的基礎(chǔ)配置之外锣吼，還有一些配置是與我們業(yè)務(wù)有關(guān)系的选浑，比如說七牛存儲、短信和郵件相關(guān)玄叠，或者一些業(yè)務(wù)上的開關(guān)古徒。

但是隨著微服務(wù)系統(tǒng)的不斷迭代，整個微服務(wù)系統(tǒng)可能會成為一個網(wǎng)狀結(jié)構(gòu)读恃，這個時候就要考慮整個微服務(wù)系統(tǒng)的擴展性隧膘、伸縮性、耦合性等等狐粱。其中一個很重要的環(huán)節(jié)就是配置管理的問題舀寓。

常規(guī)配置管理解決方案缺點：

• 硬編碼（需要修改代碼、繁瑣肌蜻、風(fēng)險大）
• properties 或者 yml（集群環(huán)境下需要替換和重啟）
• xml（重新打包和重啟）

由于常規(guī)配置管理有很大的缺點互墓，所以采用 Spring Cloud Config 或 Consul 或 Apollo 或 Nacos 等配置中心集中式的來管理每個服務(wù)的配置信息。

安全認證

從單體應(yīng)用架構(gòu)到分布式應(yīng)用架構(gòu)再到微服務(wù)架構(gòu)蒋搜，應(yīng)用的安全訪問在不斷的經(jīng)受考驗篡撵。為了適應(yīng)架構(gòu)的變化、需求的變化豆挽，身份認證與鑒權(quán)方案也在不斷的變革育谬。面對數(shù)十個甚至上百個微服務(wù)之間的調(diào)用，如何保證高效安全的身份認證帮哈？面對外部的服務(wù)訪問膛檀，該如何提供細粒度的鑒權(quán)方案？

David Borsos 在倫敦的微服務(wù)大會上提出了四種解決方案：

單點登錄（SSO）

這種方案意味著每個面向用戶的服務(wù)都必須與認證服務(wù)交互娘侍，這會產(chǎn)生大量非晨校瑣碎的網(wǎng)絡(luò)流量和重復(fù)的工作，隨著微服務(wù)應(yīng)用的增多憾筏，這種方案的弊端會更加明顯嚎杨。

分布式 Session 方案

分布式會話方案原理主要是將關(guān)于用戶認證的信息存儲在共享存儲中，且通常由用戶會話作為 Key 來實現(xiàn)的簡單分布式哈希映射氧腰。當用戶訪問微服務(wù)時枫浙，用戶數(shù)據(jù)可以從共享存儲中獲取刨肃。這種方案的缺點在于共享存儲需要一定保護機制，因此需要通過安全連接來訪問箩帚，這時解決方案的實現(xiàn)就通常具有相當高的復(fù)雜性了真友。

客戶端 Token 方案

令牌在客戶端生成，由身份驗證服務(wù)進行簽名紧帕，并且必須包含足夠的信息锻狗，以便可以在所有微服務(wù)中建立用戶身份。令牌會附加到每個請求上焕参，為微服務(wù)提供用戶身份驗證轻纪，這種解決方案的安全性相對較好，但身份驗證注銷是一個大問題叠纷，緩解這種情況的方法可以使用短期令牌和頻繁檢查認證服務(wù)等刻帚。對于客戶端令牌的編碼方案，David Borsos 更喜歡使用 JSON Web Tokens（JWT）涩嚣，它足夠簡單且?guī)熘С殖潭纫脖容^好崇众。

客戶端 Token 與 API 網(wǎng)關(guān)結(jié)合

這個方案意味著所有請求都通過網(wǎng)關(guān)，從而有效地隱藏了微服務(wù)航厚。 在請求時顷歌，網(wǎng)關(guān)將原始用戶令牌轉(zhuǎn)換為內(nèi)部會話 ID 令牌。在這種情況下幔睬，注銷就不是問題眯漩，因為網(wǎng)關(guān)可以在注銷時撤銷用戶的令牌。

總結(jié)

在微服務(wù)架構(gòu)下麻顶，我們更傾向于 David Borsos 所建議的 JWT 方案赦抖，將 OAuth2 和 JWT 結(jié)合使用，OAuth2 一般用于第三方接入的場景辅肾，管理對外的權(quán)限队萤，所以比較適合和 API 網(wǎng)關(guān)結(jié)合，針對于外部的訪問進行鑒權(quán)（當然矫钓，底層 Token 標準采用 JWT 也是可以的）要尔。

JWT 更加輕巧，在微服務(wù)之間進行認證&鑒權(quán)已然足夠新娜，并且可以避免和身份認證服務(wù)直接打交道赵辕。當然陕壹，從能力實現(xiàn)角度來說，類似于分布式 Session 在很多場景下也是完全能滿足需求棒动，具體怎么去選擇鑒權(quán)方案捉腥，還是要結(jié)合實際的需求來。

微服務(wù)架構(gòu)技術(shù)支持

Spring Cloud

• Spring Cloud Netflix Eureka：服務(wù)注冊中心具温。
• Spring Cloud Zookeeper：服務(wù)注冊中心岭佳。
• Spring Cloud Consul：服務(wù)注冊和配置管理中心怪瓶。
• Spring Cloud Netflix Ribbon：客戶端負載均衡歪今。
• Spring Cloud Netflix Hystrix：服務(wù)容錯保護嚎幸。
• Spring Cloud Netflix Feign：聲明式服務(wù)調(diào)用。
• Spring Cloud OpenFeign(可替代 Feign)：OpenFeign 是 Spring Cloud 在 Feign 的基礎(chǔ)上支持了 Spring MVC 的注解寄猩，如 @RequesMapping等等嫉晶。OpenFeign 的 @FeignClient 可以解析 SpringMVC 的 @RequestMapping 注解下的接口，并通過動態(tài)代理的方式產(chǎn)生實現(xiàn)類田篇，實現(xiàn)類中做負載均衡并調(diào)用其他服務(wù)替废。
• Spring Cloud Netflix Zuul：API 網(wǎng)關(guān)服務(wù)，過濾泊柬、安全椎镣、監(jiān)控、限流兽赁、路由状答。
• Spring Cloud Gateway(可替代 Zuul)：Spring Cloud Gateway 是 Spring 官方基于 Spring 5.0，Spring Boot 2.0 和 Project Reactor 等技術(shù)開發(fā)的網(wǎng)關(guān)刀崖，Spring Cloud Gateway 旨在為微服務(wù)架構(gòu)提供一種簡單而有效的統(tǒng)一的 API 路由管理方式惊科。Spring Cloud Gateway 作為 Spring Cloud 生態(tài)系中的網(wǎng)關(guān)，目標是替代 Netflix Zuul亮钦，其不僅提供統(tǒng)一的路由方式馆截，并且基于 Filter 鏈的方式提供了網(wǎng)關(guān)基本的功能，例如：安全蜂莉，監(jiān)控/埋點孙咪，和限流等。
• Spring Cloud Security：安全認證巡语。
• Spring Cloud Config：分布式配置中心翎蹈。配置管理工具，支持使用 Git 存儲配置內(nèi)容男公，支持應(yīng)用配置的外部化存儲荤堪，支持客戶端配置信息刷新、加解密配置內(nèi)容等枢赔。
• Spring Cloud Bus：事件澄阳、消息總線，用于在集群（例如踏拜，配置變化事件）中傳播狀態(tài)變化碎赢，可與 Spring Cloud Config 聯(lián)合實現(xiàn)熱部署。
• Spring Cloud Stream：消息驅(qū)動微服務(wù)速梗。
• Spring Cloud Sleuth：分布式服務(wù)跟蹤肮塞。
• Spring Cloud Alibaba Nacos：阿里巴巴開源產(chǎn)品襟齿，一個更易于構(gòu)建云原生應(yīng)用的動態(tài)服務(wù)發(fā)現(xiàn)、配置管理和服務(wù)管理平臺枕赵。
• Spring Cloud Alibaba Sentinel：面向分布式服務(wù)架構(gòu)的輕量級流量控制產(chǎn)品猜欺，把流量作為切入點，從流量控制拷窜、熔斷降級开皿、系統(tǒng)負載保護等多個維度保護服務(wù)的穩(wěn)定性。
• Spring Cloud Alibaba RocketMQ：一款開源的分布式消息系統(tǒng)篮昧，基于高可用分布式集群技術(shù)赋荆，提供低延時的、高可靠的消息發(fā)布與訂閱服務(wù)懊昨。
• Spring Cloud Alibaba Dubbo：Apache Dubbo? 是一款高性能 Java RPC 框架糠睡，用于實現(xiàn)服務(wù)通信。
• Spring Cloud Alibaba Seata：阿里巴巴開源產(chǎn)品疚颊，一個易于使用的高性能微服務(wù)分布式事務(wù)解決方案狈孔。
• Spring Cloud Alibaba OSS：阿里云對象存儲服務(wù)（Object Storage Service，簡稱 OSS）材义，是阿里云提供的海量均抽、安全、低成本其掂、高可靠的云存儲服務(wù)油挥。您可以在任何應(yīng)用、任何時間款熬、任何地點存儲和訪問任意類型的數(shù)據(jù)深寥。
• Spring Cloud Alibaba SchedulerX：阿里中間件團隊開發(fā)的一款分布式任務(wù)調(diào)度產(chǎn)品，提供秒級贤牛、精準惋鹅、高可靠、高可用的定時（基于 Cron 表達式）任務(wù)調(diào)度服務(wù)殉簸。
• Spring Cloud Alibaba SMS：覆蓋全球的短信服務(wù)闰集，友好、高效般卑、智能的互聯(lián)化通訊能力武鲁，幫助企業(yè)迅速搭建客戶觸達通道。

其他大哥

• RibbitMQ：RabbitMQ 是部署最廣泛的開源消息中間件蝠检。是實現(xiàn)了高級消息隊列協(xié)議（AMQP）的開源消息中間件沐鼠。
• Kafka：Kafka 是由 Apache 軟件基金會開發(fā)的一個開源流處理平臺，由Scala和Java編寫。Kafka 是一種高吞吐量的分布式發(fā)布訂閱消息系統(tǒng)饲梭。
• Redis：Redis（Remote Dictionary Server )乘盖，即遠程字典服務(wù)，是一個開源的使用 ANSI C 語言編寫排拷、支持網(wǎng)絡(luò)、可基于內(nèi)存亦可持久化的日志型锅尘、Key-Value 數(shù)據(jù)庫监氢，并提供多種語言的 API。
• MongoDB：MongoDB 是一個介于關(guān)系數(shù)據(jù)庫和非關(guān)系數(shù)據(jù)庫之間的產(chǎn)品藤违，是非關(guān)系數(shù)據(jù)庫當中功能最豐富浪腐，最像關(guān)系數(shù)據(jù)庫的。它支持的數(shù)據(jù)結(jié)構(gòu)非常松散顿乒，是類似 json 的 bson 格式议街，因此可以存儲比較復(fù)雜的數(shù)據(jù)類型。
• Elasticsearch：Elasticsearch 是一個基于 Lucene 的搜索服務(wù)器璧榄。它提供了一個分布式多用戶能力的全文搜索引擎特漩，基于 RESTful web 接口。Elasticsearch 是最受歡迎的企業(yè)搜索引擎骨杂，其次是 Apache Solr涂身，也是基于 Lucene。
• MySQL：MySQL 是一種開放源代碼的關(guān)系型數(shù)據(jù)庫管理系統(tǒng)（RDBMS）搓蚪，免費蛤售、簡單、占資源少妒潭、強大好用悴能。
• Oracle：世界上最昂貴的數(shù)據(jù)庫，一般金融系統(tǒng)使用居多雳灾。
• FastDFS：FastDFS是一個開源的輕量級分布式文件系統(tǒng)漠酿，它對文件進行管理，功能包括：文件存儲谎亩、文件同步记靡、文件訪問（文件上傳、文件下載）等团驱，解決了大容量存儲和負載均衡的問題摸吠。特別適合以文件為載體的在線服務(wù)，如相冊網(wǎng)站嚎花、視頻網(wǎng)站等等寸痢。
• HDFS：Hadoop 生態(tài)組件，可以支持千萬級的大型分布式文件系統(tǒng)紊选。
• XX-JOB：輕量級分布式任務(wù)調(diào)度平臺啼止，其核心設(shè)計目標是開發(fā)迅速道逗、學(xué)習(xí)簡單、輕量級献烦、易擴展∽仪希現(xiàn)已開放源代碼并接入多家公司線上產(chǎn)品線，開箱即用巩那。
• TX-LCN：分布式事務(wù)解決防范吏夯，LCN 并不生產(chǎn)事務(wù)，LCN 只是本地事務(wù)的搬用工（事務(wù)的協(xié)調(diào)工）即横。LCN 是一個高性能的分布式事務(wù)框架噪生，兼容 Dubbo、Spring Cloud东囚，支持 RPC 框架拓展跺嗽，支持各種 ORM 框架、NoSQL页藻、負載均衡桨嫁、事務(wù)補償。
• Zipkin：Twitter 公司開發(fā)貢獻的一款開源的分布式實時數(shù)據(jù)追蹤系統(tǒng)（Distributed Tracking System）份帐，基于 Google Dapper 的論文設(shè)計而來瞧甩，其主要功能是聚集各個異構(gòu)系統(tǒng)的實時監(jiān)控數(shù)據(jù)。
• Skywalking：Apache Skywalking 是一個開源的弥鹦，用于收集肚逸、分析，聚合彬坏，可視化來自于不同服務(wù)和本地基礎(chǔ)服務(wù)的數(shù)據(jù)的可觀察的平臺朦促。特別為分布式系統(tǒng)而設(shè)計的數(shù)據(jù)觀察和監(jiān)控系統(tǒng)。
• Apollo：攜程框架部門研發(fā)的分布式配置中心栓始，能夠集中化管理應(yīng)用不同環(huán)境务冕、不同集群的配置，配置修改后能夠?qū)崟r推送到應(yīng)用端幻赚，并且具備規(guī)范的權(quán)限禀忆、流程治理等特性，適用于微服務(wù)配置管理場景落恼。
• ConfigKeeper：隨行付架構(gòu)部基于 Spring Cloud 研發(fā)的分布式配置中心箩退。與 Spring Boot、Spring Cloud 應(yīng)用無縫兼容佳谦。
• JWT：JSON Web Token（JWT）是一個非常輕巧的規(guī)范戴涝。這個規(guī)范允許我們使用 JWT 在用戶和服務(wù)器之間傳遞安全可靠的信息。
• Nginx：Nginx 是一款輕量級的 Web 服務(wù)器/反向代理服務(wù)器及電子郵件（IMAP/POP3）代理服務(wù)器，其特點是占有內(nèi)存少啥刻，并發(fā)能力強奸鸯，中國大陸使用 Nginx 網(wǎng)站用戶有：百度、淘寶可帽、騰訊娄涩、京東、新浪映跟、網(wǎng)易等蓄拣。
• Git：開源的分布式版本控制系統(tǒng)，可以有效申窘、高速地處理從很小到非常大的項目版本管理弯蚜。
• Docker：Docker 是一個開源的應(yīng)用容器引擎孔轴，讓開發(fā)者可以打包他們的應(yīng)用以及依賴包到一個可移植的鏡像中剃法，然后發(fā)布到任何流行的 Linux 或 Windows 機器上，也可以實現(xiàn)虛擬化路鹰。容器是完全使用沙箱機制贷洲，相互之間不會有任何接口。
• Kubernetes：Kubernetes晋柱，簡稱 k8s优构，是用 8 代替 8 個字符“ubernete”而成的縮寫。Kubernetes 脫胎于 Google 的 Borg 系統(tǒng)雁竞，是一個開源的功能強大的容器編排系統(tǒng)钦椭，用于管理云平臺中多個主機上的容器化的應(yīng)用，實現(xiàn)了容器集群的自動化部署碑诉、擴容以及運維的開源平臺彪腔。Kubernetes 的目標是讓部署容器化的應(yīng)用簡單并且高效。

本文采用 知識共享「署名-非商業(yè)性使用-禁止演繹 4.0 國際」許可協(xié)議进栽。

大家可以通過 分類 查看更多關(guān)于 Spring Cloud 的文章德挣。

?? 您的點贊和轉(zhuǎn)發(fā)是對我最大的支持。

?? 關(guān)注公眾號 哈嘍沃德先生「文檔 + 視頻」每篇文章都配有專門視頻講解快毛，學(xué)習(xí)更輕松噢 ~