用微服務(wù)器替代整體應(yīng)用程序，或者建立新的應(yīng)用程序，是開發(fā)團(tuán)隊(duì)日益增長(zhǎng)的考慮因素，這些開發(fā)團(tuán)隊(duì)希望提高敏捷性，迭代速度更快，并跟上市場(chǎng)變化。通過(guò)在不同團(tuán)隊(duì)之間提供更大的自主權(quán)，允許他們并行工作，在更短的時(shí)間內(nèi)實(shí)現(xiàn)更多的功能，微服務(wù)器提供的代碼不那么脆弱，從而更容易進(jìn)行更改，測(cè)試和更新。

Docker容器適合微服務(wù)，因?yàn)樗鼈兙哂凶灾餍?，自?dòng)化和便攜性。具體來(lái)說(shuō)，Docker以其封裝特定應(yīng)用程序組件及其所有依賴關(guān)系的能力而聞名，從而使團(tuán)隊(duì)能夠獨(dú)立工作，而無(wú)需底層基礎(chǔ)架構(gòu)或底層基礎(chǔ)來(lái)支持其正在使用的每一個(gè)組件。

此外，Docker使得創(chuàng)建輕量級(jí)的隔離容器非常容易，它們可以輕巧。因?yàn)閼?yīng)用程序與底層架構(gòu)解耦，因此它十分輕便并易于使用。而且很容易創(chuàng)建一套新的容器;Docker編排解決方案(如Docker Swarm，Kubernetes或AWS ECS)可輕松地加速由多個(gè)容器組成的新服務(wù)，并全部以全自動(dòng)的方式進(jìn)行。因此，Docker非常適合微服務(wù)。

在構(gòu)建基于Docker的微服務(wù)解決方案時(shí)，有幾個(gè)過(guò)程和技術(shù)設(shè)計(jì)要考慮。以下10個(gè)考慮，有助于開發(fā)團(tuán)隊(duì)少走彎路。

[[192211]]

流程考慮：

1.現(xiàn)有的微服務(wù)將如何更新?

開發(fā)人員使用微服務(wù)的根本原因是加快開發(fā)速度，從而增加對(duì)微服務(wù)進(jìn)行更新的頻次。要充分利用微服務(wù)，這個(gè)過(guò)程是至關(guān)重要的。

但是，有幾個(gè)組成部分組成這個(gè)過(guò)程，并且在進(jìn)程的每一步都有決定。讓我們借助三個(gè)例子來(lái)解釋一下。首先，是否設(shè)置連續(xù)部署或設(shè)置人員按下儀表板的按鈕來(lái)部署新版本。權(quán)衡是更高的靈活性，持續(xù)部署，或采用手動(dòng)觸發(fā)部署的更嚴(yán)格的管理。自動(dòng)化可以允許以敏捷性實(shí)現(xiàn)安全性，并允許共同存在的好處。開發(fā)人員需要決定他們的工作流程，以及他們需要什么自動(dòng)化，以及在哪里部署。

第二，企業(yè)要考慮實(shí)際容器建設(shè)的重要性。它會(huì)在基于本地建立，推送和通過(guò)管道嗎?或者將實(shí)際代碼首先轉(zhuǎn)換成產(chǎn)品，然后轉(zhuǎn)換為一直到生產(chǎn)的Docker鏡像?如果使用容器在管道中建造的解決方案，重要的是要考慮將要建立的位置，以及要使用的工具。

第三，要考慮實(shí)際部署策略。具體來(lái)說(shuō)，可以通過(guò)藍(lán)綠色的部署設(shè)置來(lái)更新微服務(wù)體系結(jié)構(gòu)，其中一組新的容器被分離出來(lái)，然后刪除舊的容器?；蛘撸梢赃x擇滾動(dòng)更新，當(dāng)通過(guò)多個(gè)服務(wù)容器，創(chuàng)建一個(gè)新的容器，并將其投入使用。這些決定是多方面的，需要考慮幾個(gè)因素，包括當(dāng)前流量，運(yùn)營(yíng)商的技能水平以及技術(shù)方向。

2.開發(fā)商如何開始全新的服務(wù)?

開展新服務(wù)是微服務(wù)的基本要求。因此，開展全新服務(wù)的過(guò)程應(yīng)盡可能簡(jiǎn)單。在這方面，一個(gè)重要的問(wèn)題是，“如何讓開發(fā)人員以自助服務(wù)方式啟動(dòng)新服務(wù)，而不會(huì)影響安全性和治理?”它需要通過(guò)審批流程，如提交IT請(qǐng)求?或者，這將是一個(gè)完全自動(dòng)化的過(guò)程?

盡管我建議使用盡可能多的自動(dòng)化，但這絕對(duì)是開發(fā)團(tuán)隊(duì)想要提前思考的點(diǎn)，以確保他們正確平衡安全性，治理和自助服務(wù)的需求。

3.服務(wù)如何分配URL?

這個(gè)問(wèn)題真的與開創(chuàng)全新的服務(wù)緊密相連。需要在每次創(chuàng)建新的URL或子上網(wǎng)(例如myurl.com/myservice)時(shí)將其分配給新服務(wù)，并且分配它們的過(guò)程應(yīng)該理想地自動(dòng)化。選項(xiàng)可以包括一個(gè)用于手動(dòng)分配URL的自助服務(wù)門戶或一個(gè)進(jìn)程，其中URL被自動(dòng)分配并從Docker容器的名稱和應(yīng)用于Docker容器的任何標(biāo)簽中提取。

再次，就像啟動(dòng)一項(xiàng)新服務(wù)一樣，我建議在盡可能多地使用自動(dòng)化，因此需要提前花費(fèi)大量時(shí)間思考這個(gè)重要的設(shè)計(jì)點(diǎn)。

4.如何檢測(cè)和處理容器故障?

基礎(chǔ)設(shè)施的一個(gè)關(guān)鍵要求是，它不需要“保姆”，如果下降，它可以自我修復(fù)和自我恢復(fù)。因此，有一個(gè)過(guò)程來(lái)檢測(cè)故障是最重要的，以及一個(gè)計(jì)劃，當(dāng)它發(fā)生時(shí)將如何處理。例如，無(wú)論是通過(guò)網(wǎng)絡(luò)檢查還是日志解析，都必須有一個(gè)預(yù)定義的過(guò)程來(lái)檢測(cè)不再運(yùn)行的容器應(yīng)用程序。另外，應(yīng)該有一個(gè)定義的過(guò)程，用一個(gè)新的替換容器作為一個(gè)可能的解決方案。雖然這個(gè)過(guò)程有許多方法，但設(shè)計(jì)點(diǎn)是通過(guò)自動(dòng)化來(lái)確保滿足要求。

5.每個(gè)微服務(wù)的代碼如何被組織?

我們需要一個(gè)完全自動(dòng)化的流程來(lái)構(gòu)建和部署新的服務(wù)。然而，如果服務(wù)的數(shù)量很大，那么管理就會(huì)變得很麻煩。因此，應(yīng)該創(chuàng)建多個(gè)版本的進(jìn)程(每個(gè)服務(wù)一個(gè))。在這些情況下，每個(gè)過(guò)程必須保持均勻。

一個(gè)非常重要的決定就是每個(gè)微服務(wù)的結(jié)構(gòu)如何。例如，Dockerfile應(yīng)該始終出現(xiàn)在完全相同的位置，而且Dockerfile應(yīng)該包含該服務(wù)的特定內(nèi)容。同樣，其他文件(如Docker撰寫文件或AWS ECS的任務(wù)定義)應(yīng)始終放在同一個(gè)地方。跨所有服務(wù)，以便流程可以以均勻的方式一致運(yùn)行。

技術(shù)考慮：

6.將使用什么工具在計(jì)算節(jié)點(diǎn)上安排容器?

調(diào)度程序是重要的工具，因?yàn)樗鼈兎峙鋱?zhí)行作業(yè)所需的資源，將工作分配給資源和業(yè)務(wù)流程，確保在需要時(shí)可以使用執(zhí)行工作所需的資源。容器編排有許多工具選擇。通常考慮的是：針對(duì)AWS客戶的ECS，以及Docker Swarm或Kubernetes為那些希望與供應(yīng)商無(wú)關(guān)的解決方案的客戶。企業(yè)有幾個(gè)角度來(lái)決定，包括可移植性，兼容性，易于安裝，易于維護(hù)，即插即用的能力以及整體解決方案。

7.在同一服務(wù)的容器之間使用什么工具來(lái)平衡請(qǐng)求?

高可用性和在環(huán)境中擁有多個(gè)容器服務(wù)的能力使得每個(gè)微服務(wù)支持多個(gè)容器至關(guān)重要。對(duì)于非集群服務(wù)(例如，內(nèi)部開發(fā)的基于Web的微服務(wù))，需要一個(gè)外部負(fù)載均衡來(lái)平衡同一服務(wù)器上不同容器之間的流量。

這是一項(xiàng)重要的技術(shù)決策，應(yīng)該進(jìn)行徹底的評(píng)估。評(píng)估中有一些突出的設(shè)計(jì)要點(diǎn)：會(huì)話粘性的要求;計(jì)劃擁有的服務(wù)數(shù)量;每個(gè)服務(wù)的容器數(shù)量;以及想要的任何Web負(fù)載均衡算法。

8.將使用什么工具將流量路由到正確的服務(wù)?

此設(shè)計(jì)點(diǎn)與負(fù)載均衡緊密結(jié)合，因?yàn)樗苯咏鉀Q了應(yīng)用程序負(fù)載均衡問(wèn)題。如前所述，每個(gè)服務(wù)分配單個(gè)URL或子上下文。當(dāng)流量達(dá)到微服務(wù)集群時(shí)，另一個(gè)任務(wù)是確保進(jìn)入的流量被傳送到給定流量所針對(duì)的URL的正確的微服務(wù)。

哪個(gè)工具最適合應(yīng)用程序負(fù)載均衡?？赡芤笞龀稣_決策的兩個(gè)關(guān)鍵問(wèn)題是，計(jì)劃擁有多少個(gè)微服務(wù)，以及希望的路由機(jī)制復(fù)雜度。

9.什么工具將用于加密?

隨著時(shí)間的推移，特定應(yīng)用中的微服務(wù)數(shù)量增加，應(yīng)用越來(lái)越多地依賴于SaaS擴(kuò)展解決方案，安全性同時(shí)變得非常重要，更難于管理。對(duì)于微服務(wù)來(lái)進(jìn)行通信，他們通常依靠證書和API密鑰來(lái)對(duì)目標(biāo)服務(wù)進(jìn)行身份驗(yàn)證。這些API密鑰，需要安全和謹(jǐn)慎地進(jìn)行管理。隨著它們的激增，傳統(tǒng)的解決方案，如在部署時(shí)手動(dòng)插入，不起作用。坦白說(shuō)，管理的密鑰太多了，微服務(wù)需要自動(dòng)化。

企業(yè)需要通過(guò)自動(dòng)化方式來(lái)解決需要它們的容器的加密。為保存加密存儲(chǔ)建立內(nèi)部解決方案，可以即時(shí)解密，并使用環(huán)境變量將其注入容器內(nèi)。

你對(duì)這個(gè)技術(shù)問(wèn)題的回答取決于你的加密有多少?你期望這個(gè)數(shù)字如何增長(zhǎng)?安全和合規(guī)需求;以及如何愿意更改應(yīng)用程序代碼以方便處理。

10. SSL將在哪里終止?

一個(gè)經(jīng)常出現(xiàn)的問(wèn)題，特別是在服務(wù)網(wǎng)絡(luò)流量的微服務(wù)上，SSL應(yīng)該在哪里終止?要考慮的典型設(shè)計(jì)因素包括安全和合規(guī)要求。典型的選項(xiàng)是應(yīng)用程序或網(wǎng)絡(luò)負(fù)載均衡

某些合規(guī)舉措，如HIPAA，要求所有流量都被加密。因此，即使在負(fù)載均衡上進(jìn)行解密，也需要在將其發(fā)送到運(yùn)行應(yīng)用程序的容器之前重新加密。另一方面，在負(fù)載均衡上終止的優(yōu)點(diǎn)是你擁有處理SSL證書的中心位置。當(dāng)SSL證書過(guò)期或需要改變時(shí)，以便其盡量做少的更改。

作出設(shè)計(jì)決策時(shí)要考慮的因素包括具體合規(guī)性和安全性要求;應(yīng)用程序加密和解密數(shù)據(jù)的能力;容器編排平臺(tái)，因?yàn)橛行┤四軌驘o(wú)縫地加密數(shù)據(jù)。所有上述的組合應(yīng)該是你SSL終止決定的基礎(chǔ)。

正確的選擇將對(duì)企業(yè)的微型服務(wù)架構(gòu)的成功具有長(zhǎng)期的影響。設(shè)定正確規(guī)劃，基于Docker的微服務(wù)是非常重要的。