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