用微服務(wù)之前，你應(yīng)該知道的微服務(wù)知識
目前，微服務(wù)正在改變我們構(gòu)建應(yīng)用程序的方式。當(dāng)討論軟件體系架構(gòu)時(shí)，微服務(wù)無疑是最熱門的趨勢之一。現(xiàn)在，有越來越多的開發(fā)人員開始考慮使用或已經(jīng)采用了微服務(wù)。
微服務(wù)是傳統(tǒng)軟件構(gòu)造方法的替代選項(xiàng)，它讓開發(fā)人員在構(gòu)建復(fù)雜的軟件應(yīng)用時(shí)，可以具有更高的靈活性、可伸縮性以及便利性。世界上的諸多知名公司，比如 Amazon、Netflix、eBay、Spotify、Uber 和 Groupon 等都已經(jīng)意識到使用微服務(wù)帶來的優(yōu)勢。
本文總結(jié)了關(guān)于微服務(wù)的一些知識，可以方便你更快上手使用微服務(wù)。
微服務(wù)是什么？
使用微服務(wù)意味著以松耦合的模式來構(gòu)建應(yīng)用程序。在微服務(wù)模式下，我們會將程序分割成幾個(gè)小的應(yīng)用服務(wù)，每個(gè)小的服務(wù)代表一個(gè)獨(dú)立的業(yè)務(wù)目標(biāo)。
將復(fù)雜的應(yīng)用拆解為多個(gè)小的微服務(wù)后，每個(gè)服務(wù)可以使用合適的編程語言（比如 Node.js、Java、PHP 等）單獨(dú)進(jìn)行開發(fā)和維護(hù)。
微服務(wù)讓開發(fā)團(tuán)隊(duì)可以自由選擇他們最喜歡的技術(shù)棧，不用再擔(dān)心自己或別人開發(fā)的應(yīng)用因?yàn)榧夹g(shù)棧的不同而對整個(gè)應(yīng)用造成影響。與單體架構(gòu)時(shí)代相比，這使得開發(fā)人員可以更高效地操作和運(yùn)維，并且對應(yīng)用的正常運(yùn)行更有信心。
但是，這并不意味著我們可以完全拋棄單體架構(gòu)。在單體架構(gòu)與微服務(wù)架構(gòu)的選擇問題上，很多公司十分謹(jǐn)慎。確實(shí)也應(yīng)該這樣，做好準(zhǔn)確地評估是十分重要的舉措。
所以，我們接下來一起看看微服務(wù)與單體架構(gòu)之間的差異。
單體架構(gòu)與微服務(wù)架構(gòu)的對比
單體架構(gòu)意味著整個(gè)系統(tǒng)需要?jiǎng)?chuàng)建一個(gè)獨(dú)立單元作為所有功能模塊的基礎(chǔ)。該獨(dú)立單元包括數(shù)據(jù)庫操作、業(yè)務(wù)邏輯、后臺處理等。所有這些組件可以一次部署并在同一服務(wù)器上運(yùn)行。
系統(tǒng)的所有功能都編寫在一個(gè)單獨(dú)的代碼庫中，后續(xù)的所有更新也均在該代碼庫中進(jìn)行。隨著業(yè)務(wù)功能的擴(kuò)展，應(yīng)用程序會變得太過復(fù)雜而無法處理，這使得擴(kuò)展變得十分棘手。當(dāng)代碼庫較大時(shí)，為系統(tǒng)拓展新功能將會成為非常大的挑戰(zhàn)，這會嚴(yán)重限制系統(tǒng)開發(fā)和運(yùn)維的靈活性和創(chuàng)造力。
單體架構(gòu)意味著代碼過耦合。如果其中某個(gè)模塊存在問題，那么整個(gè)系統(tǒng)將崩潰，導(dǎo)致用戶無法使用。整個(gè)系統(tǒng)僅僅因?yàn)橐粋€(gè)小小的錯(cuò)誤導(dǎo)致整體無法使用，這是非常危險(xiǎn)的。
另一方面，與單體架構(gòu)不同，微服務(wù)體系結(jié)構(gòu)由多個(gè)微小的服務(wù)組成，服務(wù)之間通過相應(yīng)的 API 進(jìn)行通信。由于每個(gè)服務(wù)代表了獨(dú)立的功能，因此可以針對某個(gè)服務(wù)進(jìn)行獨(dú)立更新、部署和擴(kuò)展，而不影響其他的微服務(wù)模塊。
單體架構(gòu)主要應(yīng)用在下面幾個(gè)場景：
正在開發(fā)的應(yīng)用程序比較簡單，并且編寫的代碼模塊使用了相同的語言和框架。
如果你想要通過簡單地啟動(dòng)應(yīng)用程序來快速便捷地進(jìn)行測試，并且
整個(gè)應(yīng)用程序后期沒有太多新的功能特性引發(fā)整個(gè)應(yīng)用程序的變更。
為什么選擇使用微服務(wù)？
選擇使用微服務(wù)的原因主要有以下幾個(gè)方面：
可擴(kuò)展性
在微服務(wù)架構(gòu)中，每個(gè)服務(wù)都可以相互獨(dú)立地進(jìn)行擴(kuò)展。這意味著每個(gè)功能都可以獨(dú)立運(yùn)行，從而各個(gè)團(tuán)隊(duì)可以選擇最合適的技術(shù)棧。并且，項(xiàng)目團(tuán)隊(duì)可以估算每個(gè)功能模塊的成本，在需要時(shí)進(jìn)行相應(yīng)的修改和調(diào)整。
高生產(chǎn)力
微服務(wù)絕對是大型項(xiàng)目團(tuán)隊(duì)的必經(jīng)之路。當(dāng)他們處理費(fèi)時(shí)費(fèi)力的大型項(xiàng)目時(shí)，微服務(wù)模式允許團(tuán)隊(duì)將項(xiàng)目分為幾個(gè)相互獨(dú)立的服務(wù)。
這些服務(wù)獨(dú)立運(yùn)行。 這意味著團(tuán)隊(duì)之間可以在無需協(xié)調(diào)的情況下從事同一項(xiàng)目。從事特定微服務(wù)的團(tuán)隊(duì)可以自行制定決策，而無需等待其他團(tuán)隊(duì)的響應(yīng)。如果要開始某個(gè)新功能模塊的開發(fā)，他們完全可以自由選擇要編寫微服務(wù)的語言，而不再需要與其他團(tuán)隊(duì)正在使用的技術(shù)棧進(jìn)行協(xié)調(diào)。
敏捷性
敏捷開發(fā)是當(dāng)今大多數(shù)開發(fā)團(tuán)隊(duì)所追求的目標(biāo)。微服務(wù)架構(gòu)允許將整個(gè)團(tuán)隊(duì)分成幾個(gè)負(fù)責(zé)獨(dú)立服務(wù)的小團(tuán)隊(duì)。這不僅賦予了他們自主決策的權(quán)利，而且在多數(shù)情況下，可以通過縮短開發(fā)周期來提高生產(chǎn)效率。
可重用性
使用微服務(wù)意味著大型項(xiàng)目需要集成的代碼量會減少。項(xiàng)目中不同功能的代碼可以獨(dú)立運(yùn)行，這意味著我們可以將這些功能代碼作為基礎(chǔ)代碼或者其他功能代碼的補(bǔ)充。這樣一來，開發(fā)者可以節(jié)省大量時(shí)間，因?yàn)樗麄儾槐卦僦匦略燧喿樱恍枰脕砑从?，省時(shí)省力。
另外，所有這些功能模塊都是可以替換的。因此，如果應(yīng)用程序的某個(gè)功能模塊已經(jīng)過時(shí)，那么可以輕松地對其進(jìn)行重構(gòu)或變更替換，而不會破壞整個(gè)項(xiàng)目的功能點(diǎn)。更重要的是，我們可以隨時(shí)根據(jù)項(xiàng)目的目標(biāo)和性能需要進(jìn)行更改。
微服務(wù)面臨的挑戰(zhàn)
在決定將項(xiàng)目遷移到微服務(wù)架構(gòu)之前，你應(yīng)該了解一下未來可能面臨的一些挑戰(zhàn)：
服務(wù)間通信復(fù)雜
對于微服務(wù)架構(gòu)，應(yīng)用程序由幾個(gè)獨(dú)立運(yùn)行的服務(wù)組成，不同服務(wù)間的通信需要謹(jǐn)慎地配置。服務(wù)模塊之間會有相應(yīng)的請求，這些都需要開發(fā)人員進(jìn)行處理。對于服務(wù)間的通信，很多時(shí)候需要添加一些額外的代碼以保證服務(wù)間通信的正常進(jìn)行。如果微服務(wù)項(xiàng)目較大，服務(wù)間的通信可能會導(dǎo)致一些復(fù)雜情況的產(chǎn)生。
更多的維護(hù)成本
與所有組件運(yùn)行在同一單元中的單體架構(gòu)不同，微服務(wù)具有更多的數(shù)據(jù)庫，需要更完善的事務(wù)管理。另外，每個(gè)獨(dú)立的單元都必須分別部署和監(jiān)控。這意味著項(xiàng)目團(tuán)隊(duì)將不得不花費(fèi)更多的時(shí)間和精力來做運(yùn)維工作。
測試環(huán)節(jié)更加復(fù)雜
采用單體架構(gòu)時(shí)，我們只需要在某個(gè)服務(wù)器上啟動(dòng)應(yīng)用程序，并確保程序可以正常連接數(shù)據(jù)庫即可。而對于微服務(wù)架構(gòu)，我們擁有了更多的服務(wù)和數(shù)據(jù)庫，我們必須確保所有的服務(wù)以及數(shù)據(jù)庫正常，才能進(jìn)行下一步的測試工作。在某些情況下，某一個(gè)服務(wù)或者數(shù)據(jù)庫的異常都會導(dǎo)致測試失敗，同時(shí)影響到其他服務(wù)的正常部署和測試。
這意味著在測試上，微服務(wù)需要花費(fèi)更多時(shí)間。因?yàn)闇y試接口會有很多，并且每個(gè)功能測試需要與其他過程分開進(jìn)行。
雖然上面提到了微服務(wù)的一些缺點(diǎn)，但非常重要的一點(diǎn)是，這些問題都有一些相應(yīng)的解決方案。
微服務(wù)與 Docker
微服務(wù)通常部署在容器中，這些容器提供微服務(wù)正常運(yùn)行必須的操作系統(tǒng)環(huán)境。
Docker 是最受歡迎的容器解決方案之一。Docker 是虛擬機(jī)的輕量級系統(tǒng)，可幫助開發(fā)人員更有效地管理和部署微服務(wù)。
使用 Docker，每個(gè)微服務(wù)都放置和運(yùn)行在 Docker 鏡像和 Docker 容器中，并且完全獨(dú)立于宿主系統(tǒng)環(huán)境。
Docker 通過在其 Docker 宿主機(jī)上共享操作系統(tǒng)內(nèi)核，來實(shí)現(xiàn)自己獨(dú)立的虛擬操作系統(tǒng)環(huán)境的需求。
Docker 允許將微服務(wù)拆分為更小的代碼段，并通過Dockerfiles文件將其創(chuàng)建為Docker 鏡像。這些 Dockerfile 使得將單個(gè)服務(wù)整合到整個(gè)微服務(wù)變得更加容易。
微服務(wù)系統(tǒng)通常由多個(gè) Docker 容器構(gòu)建，這些容器通過虛擬網(wǎng)絡(luò)進(jìn)行協(xié)調(diào)通信。Docker 可以構(gòu)建 Docker Compose 環(huán)境，該環(huán)境允許服務(wù)器之間進(jìn)行通信。
Docker 通常與 Kubernetes 搭配使用。但是，他們不是競爭對手。實(shí)際上，兩者的組合可以帶來更好的結(jié)果。
微服務(wù)與 Kubernetes
Kubernetes（k8s 或“ kube”）是一個(gè)開源系統(tǒng)，用于容器的自動(dòng)化部署、擴(kuò)展和管理。它最初是由 Google 工程師開發(fā)的。自那時(shí)起，Google便將所有服務(wù)運(yùn)行在容器之上，并且每周有超過 20 億個(gè)容器上線部署。
開發(fā)者正在廣泛采用 Kubernetes 技術(shù)，因?yàn)樗尮ぷ鞲虞p松。全世界很多開發(fā)者活躍在 Kubernetes 社區(qū)，該社區(qū)有成千上萬的貢獻(xiàn)者以及許多認(rèn)證的合作伙伴。
通過將運(yùn)行的容器組織在一起，Kubernetes 可以創(chuàng)建易于管理的集群。我們可以在各種云平臺中管理這些集群，包括公共云、私有云和混合云。這便是使用 Kubernetes 可以快速擴(kuò)展云原生應(yīng)用的原因。
因此，Kubernetes 并不能替代 Docker， Docker 也不可能取代 Kubernetes。它們都可以獨(dú)立運(yùn)行。但是兩者在協(xié)作時(shí)，彼此受益。
Docker 是一種可安裝在計(jì)算機(jī)上并運(yùn)行容器化應(yīng)用的軟件。如果你的計(jì)算機(jī)上安裝了 Docker，那么可以使用 Kubernetes 自動(dòng)化容器操作，例如網(wǎng)絡(luò)管理、安全管理、擴(kuò)展管理等。如果 Docker 安裝在多個(gè) Docker 主機(jī)或節(jié)點(diǎn)上，那么可以借助 Kubernetes 執(zhí)行此操作，非常方便。
Kubernetes 管理的一組節(jié)點(diǎn)稱為Kubernetes 集群。
借助 k8s，可以實(shí)現(xiàn)很多功能：
將整個(gè)應(yīng)用拆分成在不同云環(huán)境中運(yùn)行的小容器
整合及編排容器
管理代碼庫并有效地測試獨(dú)立的輸入和輸出
即時(shí)擴(kuò)展應(yīng)用程序并加速應(yīng)用上線時(shí)間
從一家主機(jī)供應(yīng)商遷移到另一家主機(jī)供應(yīng)商，整個(gè)過程無需進(jìn)行重大更改即可實(shí)現(xiàn)
通過配置文件確保應(yīng)用程序完全按照規(guī)范運(yùn)行，方便進(jìn)行管理
可以實(shí)現(xiàn)自動(dòng)重啟，復(fù)制和擴(kuò)展應(yīng)用程序，保證程序能夠獨(dú)立修復(fù)
構(gòu)建微服務(wù)架構(gòu)
我們可以在許多不同的框架中構(gòu)建微服務(wù)。下面幾個(gè)是目前較受歡迎的，推薦給大家：
Spring Boot with Spring Cloud —基于 Java Spring Cloud 的全棧微服務(wù)框架，擴(kuò)展功能豐富。
Vert.x —運(yùn)行于 JVM 之上的一個(gè)工具，支持選擇不同語言并提供簡單的 API 接口。
Akka —一款 Actor 模型框架，非常適合響應(yīng)式微服務(wù)。
Quarkus —用于構(gòu)建模塊化微服務(wù)應(yīng)用程序的 Kurbernetes Native Java 框架
Falcon —一個(gè)專注于質(zhì)量控制并針對微服務(wù)進(jìn)行了優(yōu)化的 Python 框架。
Molecular —一款支持事件驅(qū)動(dòng)的 Node.js 微服務(wù)框架。
如何部署微服務(wù)
下面是幾種選擇。也可以選擇其中的幾個(gè)合并使用進(jìn)行微服務(wù)部署。
云上部署，擁有非常好的擴(kuò)展能力，可以為不同地區(qū)的用戶提供相應(yīng)服務(wù)
容器部署，可以大大縮短產(chǎn)品上線時(shí)間，同時(shí)可以輕松擴(kuò)展應(yīng)用并快速解決問題
PaaS（Platform-as-a-Service，平臺即服務(wù)）部署，從云提供商租用開發(fā)工具，基礎(chǔ)架構(gòu)和操作系統(tǒng)
Serverless 部署，應(yīng)對彈性的高峰流量場景時(shí)考慮使用該部署方式
構(gòu)建自己的 IT 基礎(chǔ)設(shè)施，如果有足夠的資源，可以考慮使用該方式部署。
如何對微服務(wù)進(jìn)行監(jiān)控
有很多監(jiān)控工具供你挑選使用，下面是我的一些推薦：
Datadog—該工具常用于業(yè)務(wù)監(jiān)控、日志追蹤分析以及異常告警。在異常檢測及性能監(jiān)控方面非常高效。
Dynatrace—一款由 AI 驅(qū)動(dòng)的平臺，可用于監(jiān)控動(dòng)態(tài)混合云環(huán)境。
NewRelic—一款用于云環(huán)境的集中監(jiān)控及報(bào)告的監(jiān)控工具。
Splunk—一款用于日志分析的輕便工具。
AppDynamix—一款實(shí)時(shí)監(jiān)控應(yīng)用程序和服務(wù)器性能的工具。
— 一個(gè)開源的性能監(jiān)控及網(wǎng)絡(luò)監(jiān)控工具。
如何自動(dòng)化CI/CD過程
從完整的云基礎(chǔ)架構(gòu)設(shè)置到使用 Kubernetes 在云中交付應(yīng)用程序和服務(wù)，Microtica涵蓋整個(gè)軟件交付自動(dòng)化過程。Microtica 針對開發(fā)人員在云中開發(fā)、測試和代碼部署的方式制定了相應(yīng)標(biāo)準(zhǔn)。這讓他們的工作在未來的項(xiàng)目中得以復(fù)用。
如何進(jìn)行測試
下面是我們使用的一些方法：
使用Postman進(jìn)行 API 自動(dòng)化測試。我們?yōu)槊總€(gè)公共 API 定義了一個(gè)測試用例，在每天凌晨時(shí)執(zhí)行它們，并立即獲得測試報(bào)告。如果出現(xiàn)問題時(shí)，我們會立即修復(fù)問題并將變更部署到生產(chǎn)環(huán)境。
何時(shí)使用微服務(wù)？
在以下幾個(gè)情況，微服務(wù)架構(gòu)是最佳解決方案：
項(xiàng)目未來會有很多新功能
項(xiàng)目經(jīng)常發(fā)布新功能
項(xiàng)目有多個(gè)子域名及子服務(wù)
公司業(yè)務(wù)正在計(jì)劃擴(kuò)張
項(xiàng)目有一個(gè)大型團(tuán)隊(duì)可以同時(shí)處理不同的微服務(wù)
擁有敏捷的、跨職能的團(tuán)隊(duì)并且正在進(jìn)行大型的項(xiàng)目協(xié)作
但是，在開始使用微服務(wù)架構(gòu)前，請務(wù)必仔細(xì)考慮下面幾個(gè)問題：
項(xiàng)目需要多少存儲空間？如果項(xiàng)目依賴本地存儲，則將無法靈活地進(jìn)行服務(wù)擴(kuò)展。應(yīng)用也將無法處理大量工作負(fù)載。
應(yīng)用程序是事件驅(qū)動(dòng)嗎？如果是這樣，那么程序應(yīng)該能實(shí)現(xiàn)異步處理，因?yàn)槟愕膽?yīng)用程序?qū)⒖缍嗯_機(jī)器進(jìn)行部署擴(kuò)展。
需要靈活的消息傳輸機(jī)制。微服務(wù)項(xiàng)目中有多個(gè)事件源，并且都必須對其進(jìn)行處理。因此，需要一個(gè)強(qiáng)大的消息傳遞模型。
由于微服務(wù)將使用其 API 進(jìn)行通信，因此創(chuàng)建API 通信模式是必不可少的。
微服務(wù)需要一個(gè)更加安全的模型，該模型允許一個(gè)微服務(wù)僅能訪問其所需的資源，而不會使其他微服務(wù)受到安全威脅。 微服務(wù)在軟件體系架構(gòu)方面進(jìn)行了重大的革命。在構(gòu)建微服務(wù)應(yīng)用時(shí)，應(yīng)認(rèn)真考慮各種情況。 Netflix、Amazon、Uber 和 Spotify 決定將微服務(wù)架構(gòu)應(yīng)用于構(gòu)建各自大型復(fù)雜的應(yīng)用程序，以充分利用微服務(wù)的特有優(yōu)勢。然而，能夠充分做到微服務(wù)架構(gòu)并發(fā)揮其優(yōu)勢的，僅僅是科技巨頭中的一小部分而已。 但是，是否遷移到微服務(wù)應(yīng)取決于項(xiàng)目以及團(tuán)隊(duì)結(jié)構(gòu)。這對整個(gè)公司來說都是非常重要的，因此在使用微服務(wù)之前，應(yīng)該認(rèn)真進(jìn)行討論和評估。
原文鏈接：
https://hackernoon.com/how-to-start-using-microservices-0e1z3