原文鏈接:Introduction to Microservices
- 微服務(wù)介紹(本文)
- 構(gòu)建微服務(wù)之使用API網(wǎng)關(guān)
- 構(gòu)建微服務(wù)之:微服務(wù)架構(gòu)中的進(jìn)程間通信
- 微服務(wù)中的服務(wù)發(fā)現(xiàn)
- 微服務(wù)之事件驅(qū)動(dòng)的數(shù)據(jù)管理
- 選擇一種微服務(wù)部署策略
- 重構(gòu)單體應(yīng)用到微服務(wù)
微服務(wù)現(xiàn)在受到了大量的關(guān)注︰ 文章、 博客、 社交媒體和學(xué)術(shù)會(huì)議上的討論都能看到該詞匯的身影。微服務(wù)正迅速走向 Gartner Hype cycle 所指的快速發(fā)展期。同時(shí)，軟件社區(qū)的一些懷疑論者指出微服務(wù)并不是什么新鮮玩意兒。這些唱反調(diào)的人說微服務(wù)和SOA概念并沒有什么不同，舊瓶裝新酒而已，順勢(shì)炒炒新概念。然而，不管說是夸大也好，懷疑也罷，微服務(wù)架構(gòu)模式應(yīng)用在敏捷開發(fā)和交付復(fù)雜的企業(yè)應(yīng)用程序的時(shí)候還是有巨大優(yōu)勢(shì)的 。
本博客是設(shè)計(jì)、構(gòu)建和部署微服務(wù)七篇博客系列的開篇。通過該文章將學(xué)到一些微服務(wù)的方法，還有微服務(wù)架構(gòu)與傳統(tǒng)單體式架構(gòu)模式的比較。本系列將介紹微服務(wù)架構(gòu)的各種元素，并揭示該架構(gòu)模式的各種優(yōu)點(diǎn)與缺點(diǎn)，以此來指導(dǎo)微服務(wù)是否適合您的項(xiàng)目，以及如何運(yùn)用該模式。
讓我們首先看看為什么你應(yīng)該考慮使用微服務(wù)。
構(gòu)建單體式應(yīng)用
假設(shè)現(xiàn)在我們?yōu)榱伺cUber和Hailo競(jìng)爭(zhēng)來構(gòu)建一個(gè)全新在線打車軟件:經(jīng)過一系列的預(yù)備會(huì)議和需求收集，我們決定無論是人工擼還是用Rails，Spring Boot，Play，或Maven之類工具生成也好，最終要?jiǎng)?chuàng)建一個(gè)全新的應(yīng)用！應(yīng)用應(yīng)該有如下圖六邊形一樣的模塊結(jié)構(gòu)
應(yīng)用程序的核心是業(yè)務(wù)邏輯，它了定義服務(wù)、 領(lǐng)域?qū)ο蠛褪录K。圍繞核心是接口與外部世界的適配器。適配器的例子包括數(shù)據(jù)庫訪問組件、 生產(chǎn)消息和消費(fèi)消息的消息傳遞組件以及暴露API或?qū)崿F(xiàn)用戶界面的 web 組件。
盡管在邏輯上模塊化，整個(gè)應(yīng)用還是做為一個(gè)巨大的整體進(jìn)行打包和部署的。而且模塊的結(jié)構(gòu)往往與選擇的編程語言和框架緊密相關(guān)。 舉個(gè)栗子： 多數(shù)java程序打成war包部署到Tomcat 、Jetty等應(yīng)用服務(wù)器中；還有一部分被打成自包含的jar包（Spring Boot支持把jetty或者tomcat包進(jìn)去，以main為入口啟動(dòng)應(yīng)用）； 同樣的，Rails 和 Node.js 應(yīng)用直接以目錄結(jié)構(gòu)的方式部署.
這種風(fēng)格開發(fā)的應(yīng)用是非常常見的。我們的IDE和工具致力于構(gòu)建這樣的單一應(yīng)用，所以我們開發(fā)起來也感覺到簡(jiǎn)單；此類應(yīng)用測(cè)試起來也很方便，你可以很簡(jiǎn)單的啟動(dòng)這個(gè)應(yīng)用，采用selenium測(cè)試UI去完成端到端的測(cè)試；單體應(yīng)用部署起來也不難，把包一拷貝扔服務(wù)器里就妥了， 如果要擴(kuò)展應(yīng)用，只需要在負(fù)載均衡器后面跑多個(gè)相同的應(yīng)用就可以了。工程的初期呢，這個(gè)方法工作的還是不錯(cuò)的！
邁向單體的地獄
很不幸的是，這種方式還是有巨大的局限性的.。一個(gè)成功的應(yīng)用總會(huì)隨著時(shí)間逐步成長(zhǎng)并變得巨大起來。每個(gè)敏捷Sprint周期，開發(fā)者會(huì)實(shí)現(xiàn)更多的功能，當(dāng)然這就意味著又添加了很多行代碼。幾年之后你會(huì)發(fā)現(xiàn)，當(dāng)年你寫的那個(gè)簡(jiǎn)單的小小的應(yīng)用居然變成一個(gè)巨大的單體怪物。舉一個(gè)比較極端的例子吧：最近我和一個(gè)開發(fā)者聊天，他正在寫一個(gè)工具來分析數(shù)百萬行代碼的巨大應(yīng)用中的上千個(gè)jar的依賴關(guān)系。別的不說，寫出這么巨大的怪物肯定花費(fèi)了很多程序員幾年的時(shí)間。
一旦應(yīng)用變成了巨大復(fù)雜的單體，那你的開發(fā)團(tuán)隊(duì)將痛苦不堪！敏捷開發(fā)和交付的一些愿景在這個(gè)龐然大物面前都會(huì)受挫。最主要的問題就是這玩意兒現(xiàn)在太復(fù)雜了！復(fù)雜到很難有某個(gè)程序員能完全理解它！導(dǎo)致結(jié)果就是，正確的修個(gè)bug、做個(gè)新功能變的費(fèi)時(shí)又費(fèi)力。更可恨的是，這是一個(gè)惡性循環(huán)的過程，應(yīng)用正在逐步的‘死去’ 。如果你的代碼庫別人都理解不了，那么對(duì)代碼做點(diǎn)正確的改動(dòng)是很難的，最終這個(gè)怪物更加的可怕更加的難以理解，糾結(jié)！
應(yīng)用程序的規(guī)模大了也會(huì)拖慢程序的開發(fā)： 程序越大，啟動(dòng)越慢！調(diào)查顯示一些程序員說他們啟動(dòng)程序要12分鐘，我個(gè)人還聽過有的應(yīng)用啟動(dòng)要40分鐘！程序員開發(fā)過程需要周期性的重啟應(yīng)用，這樣就浪費(fèi)了很多時(shí)間，效率自然也很低下，不能忍！
巨大、復(fù)雜的單體應(yīng)用還是持續(xù)交付的巨大障礙?，F(xiàn)在SaaS應(yīng)用的宗旨是如果有改動(dòng)能夠每天部署多次。單體應(yīng)用的中某部分的改動(dòng)需要需要重新部署整個(gè)應(yīng)用，這樣的話持續(xù)交付是相當(dāng)困難的。前面也講了，啟動(dòng)一次就要那么久 ！另外，改動(dòng)造成的影響也不是很好被理解，需要大量的手工測(cè)試去保證，這樣的話持續(xù)交付更是難上加難了！
單體應(yīng)用在多個(gè)模塊對(duì)資源需求上有沖突時(shí)很難進(jìn)行擴(kuò)展。比如：一個(gè)新模塊可能實(shí)現(xiàn)了CPU密集型的圖片處理邏輯,更適合部署到Amazon EC2 Compute Optimized instances。另一個(gè)模塊可能需要一個(gè)內(nèi)存數(shù)據(jù)庫，更適合使用EC2 Memory-optimized instances。然而，這些模塊必須被一起部署的話，選擇硬件的時(shí)候就要好好折中一下嘍。
單體應(yīng)用的另一個(gè)問題是穩(wěn)定性：因?yàn)樗械哪K都跑在同一進(jìn)程之中，某模塊中的bug，比如內(nèi)存泄漏是可能拖垮整個(gè)應(yīng)用的！更重要的是，因?yàn)樨?fù)載均衡后面的所有的應(yīng)用是一樣的，bug還可能影響整個(gè)應(yīng)用的可用性！
最后重要的一點(diǎn)：?jiǎn)误w應(yīng)用很難擁抱新的框架和編程語言。假設(shè)你有2百萬行用XYZ框架寫的代碼，如果用ABC框架重寫它將會(huì)耗費(fèi)巨大的時(shí)間和金錢！哪怕大家都知道用新框架更適合一些（攤手）。這樣導(dǎo)致的結(jié)果是，在嘗試轉(zhuǎn)換新框架新技術(shù)的時(shí)候存在巨大的障礙，我們不得不繼續(xù)在選型之初定好的技術(shù)架構(gòu)上前行（哭臉）。
最后總結(jié)下吧，你從擁有一個(gè)業(yè)務(wù)清晰，幾個(gè)程序員都明白的小程序，逐步的變成了一個(gè)可怕的單體應(yīng)用?；厥卓催@個(gè)應(yīng)用是采用了過時(shí)的、效率低下的技術(shù)來寫的（畢竟技術(shù)在進(jìn)步，抱著老東西悶頭陶醉不是什么好事情）！別的不說，招聘都費(fèi)勁吶！這個(gè)單體應(yīng)用變的難以擴(kuò)展、變得極不穩(wěn)定，想敏捷開發(fā)？想持續(xù)交付？ 恐怕只能呵呵了。
面對(duì)這些，你能做點(diǎn)什么呢？
微服務(wù) – 處理這些復(fù)雜問題！
很多機(jī)構(gòu)，比如Amazon、eBay、Netflix，已經(jīng)開始通過擁抱微服務(wù)架構(gòu)去解決上述的問題了。她們不再去構(gòu)建一個(gè)可怕的單體應(yīng)用，而是拆分成多個(gè)更小的、相互連接的微服務(wù)！
服務(wù)通常實(shí)現(xiàn)了一系列相互獨(dú)立的功能或特性，比如訂單管理、客戶管理等等。每一個(gè)微服務(wù)都具有自身業(yè)務(wù)邏輯以及各種適配器構(gòu)成的六角形架構(gòu)模式，都是一個(gè)迷你的小應(yīng)用。有的微服務(wù)會(huì)暴露API供其他微服務(wù)和客戶消費(fèi)，其他微服務(wù)則可能實(shí)現(xiàn)Web UI。運(yùn)行時(shí)，每一個(gè)實(shí)例通常是云平臺(tái)的一個(gè)VM或者一個(gè)Docker容器。
下面是對(duì)上述老架構(gòu)的一個(gè)拆分：
應(yīng)用的每個(gè)功能區(qū)域現(xiàn)在都以微服務(wù)的方式來實(shí)現(xiàn)了，此外整個(gè)應(yīng)用被拆分成一系列更小的web應(yīng)用（比如乘客管理、司機(jī)管理）。拆分之后更加方便的為特殊用戶、設(shè)備或者特殊用例進(jìn)行部署。
每一個(gè)后端服務(wù)都暴露REST API，絕大部分服務(wù)也會(huì)消費(fèi)其他服務(wù)提供的API。比如，司機(jī)管理服務(wù)會(huì)使用通知服務(wù)告知空閑的司機(jī)潛在的行程（來生意了，接單?。贿€有UI 服務(wù)會(huì)調(diào)用其他服務(wù)后渲染web頁面。服務(wù)之間也會(huì)使用異步的，基于消息的通信模式，微服務(wù)進(jìn)程間的通信將會(huì)在后面的文章詳述。
一些REST API 也會(huì)暴露給移動(dòng)端設(shè)備方便司機(jī)和乘客的使用。當(dāng)然，這些應(yīng)用不會(huì)直接訪問后端各個(gè)微服務(wù) ，而是通過一個(gè)協(xié)調(diào)者API網(wǎng)關(guān)來訪問的。 API網(wǎng)關(guān)的職責(zé)有負(fù)載均衡、緩存、訪問控制、API計(jì)費(fèi)、監(jiān)控···，這些事情使用NGINX就OK啦。后面的文章將會(huì)講述API網(wǎng)關(guān)的細(xì)節(jié)。
微服務(wù)架構(gòu)模式很契合上圖的Y軸擴(kuò)展方式，上圖X軸的擴(kuò)展表示橫向擴(kuò)展應(yīng)用，一般就是負(fù)載均衡器后面部署幾個(gè)相同的應(yīng)用。Z軸擴(kuò)展表示數(shù)據(jù)分區(qū),將請(qǐng)求路由到特定的服務(wù)器上（比如數(shù)據(jù)庫分庫分表，根據(jù)主鍵訪問到用戶記錄對(duì)應(yīng)的數(shù)據(jù)庫）。
應(yīng)用一般都會(huì)三個(gè)維度去擴(kuò)展。Y軸正是按照我們第一節(jié)講到的，把單體應(yīng)用拆分為微服務(wù)，運(yùn)行時(shí)呢，為了某個(gè)服務(wù)達(dá)到高吞吐和高可用性，可以采用負(fù)載均衡，也就是X軸擴(kuò)展了，特殊應(yīng)用也會(huì)使用Z軸擴(kuò)展來切分服務(wù)。下面的圖展示了行程管理采用Docker鏡像部署到Amazon EC2的情況：
運(yùn)行時(shí)，行程管理由多個(gè)服務(wù)實(shí)例組成。每個(gè)應(yīng)用實(shí)例實(shí)際是一個(gè)Docker容器。為了達(dá)到高可用，容器會(huì)跑在多個(gè)云平臺(tái)VM上，服務(wù)實(shí)例之前是NGINX這樣的負(fù)載均衡器來分發(fā)請(qǐng)求，負(fù)載均衡器也會(huì)關(guān)注比如緩存、權(quán)限訪問、服務(wù)計(jì)費(fèi)、監(jiān)控等事宜。
微服務(wù)架構(gòu)模式極大的影響應(yīng)用和數(shù)據(jù)庫之間的關(guān)系。每個(gè)微服務(wù)都會(huì)有自己的數(shù)據(jù)庫Schema，而不是和其他服務(wù)共享一套數(shù)據(jù)庫Shcema。另一個(gè)角度看，這種方式對(duì)于以往企業(yè)級(jí)范圍的數(shù)據(jù)模型來講是很奇怪的，另外，微服務(wù)這么搞會(huì)造成數(shù)據(jù)冗余。然而，如果你想從微服務(wù)架構(gòu)獲益，那么每個(gè)微服務(wù)一個(gè)數(shù)據(jù)Schema是很有必要的，因?yàn)槲⒎?wù)提倡的就是松耦合啊，下面的圖展示了微服務(wù)架構(gòu)下應(yīng)用的數(shù)據(jù)架構(gòu)：
每個(gè)微服務(wù)都有自己的數(shù)據(jù)庫，而且每個(gè)服務(wù)還能選擇適合自己需求的數(shù)據(jù)庫，這就是所謂的多態(tài)型持久化架構(gòu)。比如，司機(jī)如果需要查找附近的潛在乘客，那就必須要使用支持高效地理位置查詢的數(shù)據(jù)庫。
表面上看微服務(wù)和SOA架構(gòu)很相似，兩種架構(gòu)都倡導(dǎo)由一系列的服務(wù)組成。我們可以把微服務(wù)架構(gòu)模式當(dāng)成是沒有商業(yè)web service規(guī)范（WS規(guī)范咯）以及ESB等打包套件約束的SOA。基于微服務(wù)架構(gòu)的應(yīng)用更傾向于簡(jiǎn)單的、輕量級(jí)的REST協(xié)議而不是老舊的WS，當(dāng)然，微服務(wù)也會(huì)避免去使用笨重的ESB套件而更喜歡去實(shí)現(xiàn)一些ESB部分功能的輕量級(jí)工具（不要捆綁，不要全家桶?。?，微服務(wù)架構(gòu)模式也避免SOA中諸如規(guī)范化Schema的定義。
微服務(wù)的優(yōu)勢(shì)
微服務(wù)架構(gòu)模式有很多重要的優(yōu)勢(shì)。首先，通過把可怕巨大的單體拆分為一系列的服務(wù)解決了單體復(fù)雜度問題， 拆分后整體功能數(shù)量并沒有變化，但是應(yīng)用現(xiàn)在變成了多個(gè)方便管理的小應(yīng)用，每個(gè)服務(wù)都有一個(gè)定義良好的服務(wù)邊界，通過RPC方式或消息驅(qū)動(dòng)暴露API。微服務(wù)架構(gòu)模式解決了單體應(yīng)用代碼庫在實(shí)踐中極難模塊化的難題，拆分后的微服務(wù)能夠更快的部署，更易理解和維護(hù)！
第二，拆分后的服務(wù)可以被專注于某部分服務(wù)的團(tuán)隊(duì)獨(dú)立開發(fā)。程序員可以基于API約定前提下自由選擇合適的技術(shù)，當(dāng)然，很多機(jī)構(gòu)為了避免技術(shù)選擇混亂也會(huì)限制技術(shù)的選項(xiàng)。因此，自由意味著程序員可以不再局限于項(xiàng)目初期選擇的技術(shù)了（撒花）！開始寫一個(gè)新的微服務(wù)的時(shí)候，開發(fā)者可以使用一些當(dāng)下流行的技術(shù)，更重要的是，因?yàn)槊總€(gè)服務(wù)現(xiàn)在拆分的很小，使用現(xiàn)有技術(shù)重寫老的服務(wù)成為可能！
第三，微服務(wù)架構(gòu)模式使得獨(dú)立部署成為可能，開發(fā)者不用再忙碌于協(xié)調(diào)其他模塊的變化再去部署（單體應(yīng)用，改一個(gè)部分可能對(duì)其他部分影響，某個(gè)更改可能涉及多個(gè)模塊的協(xié)調(diào)），微服務(wù)的更改可以在測(cè)試后盡快的被部署。比如，UI組可以進(jìn)行A/B測(cè)試并且快速迭代而不用等待整個(gè)應(yīng)用部署。微服務(wù)架構(gòu)模式使得持續(xù)部署成為可能！
最后，微服務(wù)架構(gòu)模式使得每個(gè)服務(wù)可以獨(dú)立的擴(kuò)展。我們可以針對(duì)某些有容量和可用性要求的微服務(wù)進(jìn)行擴(kuò)展，為需要的服務(wù)部署多個(gè)實(shí)例而不是復(fù)制多個(gè)單體去折中獲得某項(xiàng)提升！更重要的是，我們可以針對(duì)服務(wù)需求使用最合適的硬件資源。比如，我們可以把CPU密集型的圖片處理服務(wù)部署到EC2 Compute Optimized instances，部署內(nèi)存數(shù)據(jù)庫相關(guān)的服務(wù)到EC2 Memory-optimized instances。
微服務(wù)的劣勢(shì)
正如Fred 30年前的書中所說,“沒有銀彈！”。和其他技術(shù)一樣，微服務(wù)架構(gòu)也有其劣勢(shì) 。劣勢(shì)之一就是它的名字（捂臉），微服務(wù)這個(gè)詞過分強(qiáng)調(diào)了服務(wù)的尺寸，實(shí)際上還真有幾個(gè)開發(fā)者號(hào)召大家寫10-100行代碼的‘微服務(wù)’（這應(yīng)該不太可能吧）！然而微服務(wù)更想表達(dá)的是一種工具和途徑，微并不是最終的目標(biāo)（為微服務(wù)而微服務(wù)，敲響警鐘），微服務(wù)是為了便利敏捷開發(fā)和部署而去有效的拆分應(yīng)用。
微服務(wù)另一個(gè)劣勢(shì)是因?yàn)閺膯误w應(yīng)用拆分為分布式系統(tǒng)帶來的復(fù)雜。開發(fā)者需要選擇或者實(shí)現(xiàn)基于消息或者RPC模式的進(jìn)程間通訊機(jī)制，另外開發(fā)者也要寫額外的代碼去處理對(duì)于目的服務(wù)請(qǐng)求可能存在的請(qǐng)求緩慢或者請(qǐng)求不可用導(dǎo)致的局部故障問題。分布式系統(tǒng)可不是什么火箭科學(xué)，它可比單體應(yīng)用中模塊間通過語言層面或者進(jìn)程內(nèi)調(diào)用復(fù)雜的多了！
微服務(wù)另一個(gè)挑戰(zhàn)就是拆分?jǐn)?shù)據(jù)庫架構(gòu)。一個(gè)邏輯事務(wù)更新多個(gè)業(yè)務(wù)記錄是很常見的事情，單體應(yīng)用實(shí)現(xiàn)該事務(wù)是比較簡(jiǎn)單的，畢竟大家使用一個(gè)數(shù)據(jù)庫。然而在微服務(wù)架構(gòu)中，你必須要更新多個(gè)服務(wù)的多個(gè)數(shù)據(jù)庫。一般不會(huì)使用分布式事務(wù)，不僅僅是因?yàn)镃AP理論，還因?yàn)橐恍┝餍械腘oSQL數(shù)據(jù)庫和Message Queue系統(tǒng)壓根也不支持（攤手）。最后還得繞回最終一致性方案，這個(gè)方案對(duì)開發(fā)者來講也是略有挑戰(zhàn)的（實(shí)際上我看這個(gè)系列的文章并且開始翻譯也是因?yàn)閷?shí)際中遇到了這個(gè)問題，下面的文章將會(huì)提到）。
測(cè)試微服務(wù)架構(gòu)的應(yīng)用也是更加復(fù)雜的。比如，使用Spring Boot這種框架，開發(fā)者啟動(dòng)一個(gè)單體應(yīng)用去寫一些測(cè)試用例、測(cè)試其REST API是很平常事情。相反的是，相類似的測(cè)試在微服務(wù)中的話，你要啟動(dòng)或者至少去mock其依賴的其他的服務(wù)才能完成。再次強(qiáng)調(diào)，微服務(wù)不是火箭科學(xué)，很重要的一點(diǎn)是大家不要低估了這樣做的復(fù)雜度！
微服務(wù)架構(gòu)模式的另一巨大挑戰(zhàn)是實(shí)現(xiàn)跨服務(wù)的改動(dòng)。比如，讓我們假設(shè)你要實(shí)現(xiàn)一個(gè)需要更改服務(wù)A、B、C的功能，而此時(shí)A依賴于B，B依賴于C。在傳統(tǒng)單體應(yīng)用中，你可以很簡(jiǎn)單的去更改對(duì)應(yīng)的模塊，集成這些變動(dòng)然后一起部署它們。然而在微服務(wù)架構(gòu)模式下，你需要小心翼翼的計(jì)劃和協(xié)調(diào)每個(gè)服務(wù)的改動(dòng)和發(fā)布：你需要更新服務(wù)C，再更新服務(wù)B，然后還要更新服務(wù)A。幸運(yùn)的是，絕大部分時(shí)候一個(gè)服務(wù)的變化僅會(huì)影響一個(gè)服務(wù)，多個(gè)服務(wù)間需要協(xié)調(diào)的情況是很少出現(xiàn)的。
部署一個(gè)基于微服務(wù)架構(gòu)的應(yīng)用是更加復(fù)雜的。一個(gè)傳統(tǒng)單體應(yīng)用可以簡(jiǎn)單的部署到負(fù)載均衡器后面，因?yàn)閼?yīng)用都是相同的，拷貝部署就可以了。每個(gè)應(yīng)用配置好數(shù)據(jù)庫和message broker的地址（主機(jī)和端口）就好了。相對(duì)應(yīng)的微服務(wù)一般是大量的服務(wù)組成的，比如，Hailo存在160個(gè)不同的服務(wù)，Netflix則有多達(dá)600多個(gè)不同服務(wù)，每個(gè)服務(wù)還有多個(gè)運(yùn)行實(shí)例！將會(huì)有更多的變化的部分需要去配置、部署、擴(kuò)展、監(jiān)控。此外還需要實(shí)現(xiàn)一個(gè)服務(wù)發(fā)現(xiàn)機(jī)制讓其他服務(wù)找到它需要通信的服務(wù)的地址。傳統(tǒng)的基于Ticket和手動(dòng)運(yùn)維的方式是不可能處理好這個(gè)級(jí)別的復(fù)雜擴(kuò)展的。因此，成功部署一個(gè)微服務(wù)需要開發(fā)者對(duì)部署方法有更多控制還要對(duì)服務(wù)執(zhí)行高水平的自動(dòng)化。
自動(dòng)化的其中一種方式是使用現(xiàn)有的Paas平臺(tái)（比如Cloud Foundry）。PaaS平臺(tái)為開發(fā)者提供了便捷的方式去部署他們的微服務(wù)，避免了是他們糾纏于購買和配置IT資源的泥潭。同時(shí)，配置PaaS系統(tǒng)和網(wǎng)絡(luò)的專業(yè)人員可以確保遵守了最佳實(shí)踐和公司策略。另一種自動(dòng)化方式就是開發(fā)自己的PaaS平臺(tái)。一個(gè)典型的開端就是先使用集群方案（比如Kubernetes）配合上Docker容器技術(shù)，后續(xù)的文章將會(huì)介紹基于軟件的應(yīng)用交付方案，比如NGINX是如何在微服務(wù)層面方便的處理緩存、訪問控制、API計(jì)費(fèi)、監(jiān)控等問題的。
總結(jié)
構(gòu)建復(fù)雜的應(yīng)用本身就是困難的事情。單體應(yīng)用架構(gòu)在針對(duì)簡(jiǎn)單、輕量級(jí)的應(yīng)用的時(shí)候是很好的。但是一旦你把那套方案運(yùn)用在復(fù)雜的應(yīng)用的時(shí)候你將會(huì)痛苦不堪。盡管微服務(wù)架構(gòu)模式有諸多缺點(diǎn)和實(shí)現(xiàn)上的挑戰(zhàn)，但對(duì)于復(fù)雜的、演進(jìn)的應(yīng)用來講是一個(gè)更好的選擇。
在后續(xù)的文章中我將會(huì)詳細(xì)介紹微服務(wù)的幾個(gè)方面，討論一些諸如服務(wù)發(fā)現(xiàn)、服務(wù)部署選擇以及重構(gòu)單體應(yīng)用到微服務(wù)的的話題。
后記
第一篇文章翻譯完了，說實(shí)話膽顫心驚，第一次作大死，厚著臉皮上吧?。?！
