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