python微服務開發1微服務簡介
微服務的起源
微服務沒有官方標準。當人們試圖解釋什麼是微服務時經常會提到面向服務的體系結構(SOA Service-Oriented Architecture)。
SOA predates microservices, and its core principle is the idea that you organize applications into a discrete unit of functionality that can be accessed remotely and acted upon and updated independently.
中文翻譯：SOA早於微服務，其核心原則是將應用程式組織成獨立的功能單元，可以遠端訪問並獨立操作和更新。
Wikipedia上述定義中的每個單元都是獨立服務，它實現了業務的一個方面，並通過某個介面提供其功能。雖然SOA明確指出服務應該是獨立的流程，但它並不強制應該使用哪些協議來使這些流程相互互動，並且對於如何部署和組織應用程式保持相當模糊。
SOA服務可以通過程序間通訊(IPC Inter-Process Communication)使用同一臺機器上的套接字，共享記憶體，間接訊息佇列，甚至遠端過程呼叫（RPC Remote ProcedureCalls）進行通訊。
通常微服務是SOA的專業版，如果我們想要給出什麼是微服務的完整定義，那麼最好的方法是首先看看大多數軟體是如何構建的。
集中式架構
比如：酒店預訂網站。
除了靜態HTML內容，該網站還有預訂功能，可以讓使用者預訂世界上任何城市的酒店。使用者可以搜尋酒店，然後使用信用卡預訂。
當用戶在酒店網站上執行搜尋時，該應用程式將執行以下步驟：
一旦使用者找到了完美的酒店並點選它進行預訂，應用程式就會執行以下步驟：
- 如果需要，客戶將在資料庫中建立，並且必須進行身份驗證。
- 通過與銀行網路服務進行互動來執行付款。
- 出於法律原因，該應用將付款詳細資訊儲存在資料庫中。
- 使用PDF生成器生成收據。
- 使用電子郵件服務向用戶傳送回顧電子郵件。
- 使用電子郵件服務將預訂電子郵件轉發給第三方酒店。
- 新增資料庫條目以跟蹤預訂。
這是簡化但非常現實模型，應用程式與包含酒店資訊，預訂詳細資訊，賬單，使用者資訊等的資料庫進行互動。它還與外部服務互動，用於傳送電子郵件，付款以及從合作伙伴處獲取更多酒店。
在舊的LAMP（Linux-Apache-MySQL-Perl / PHP / Python）體系結構中，每個傳入的請求都會在資料庫上生成一連串的SQL查詢，並對外部服務進行一些網路呼叫，然後伺服器生成HTML響應使用模板引擎。
下圖說明了這種集中式架構：
圖片.png
好處：
-
整個應用程式都在一個程式碼庫中，當專案編碼開始時，它使一切變得更簡單。構建良好的測試覆蓋率非常簡單，您可以在程式碼庫中以乾淨，結構化的方式組織程式碼。將所有資料儲存到單個數據庫中也簡化了應用程式的開發。您可以調整資料模型，以及程式碼如何查詢方式。
-
部署也毫不費力：我們可以標記程式碼庫，打包，然後在某個地方執行它。為了擴充套件它，我們可以執行預訂應用程式的多個例項，並執行一些具有一些複製機制的資料庫。
如果您的應用程式較小，此模型執行良好，並且易於單個團隊維護。
如果專案通常在增長，將整個應用程式放在一個程式碼庫中會帶來一些令人討厭的問題。例如，如果您需要進行範圍較大的徹底更改（例如更改銀行服務或資料庫層），整個應用程式將進入非常不穩定的狀態。這些變化在專案的生命週期中是一個大問題，他們需要進行大量額外測試才能部署新版本。
由於系統的不同部分具有不同的正常執行時間和穩定性要求，因此小的變化也會產生附帶損害。由於建立PDF的功能導致伺服器崩潰，因此將計費和預留流程置於風險中是一個問題。
不受控制的增長是另一個問題。應用程式必然會獲得新功能，並且開發人員離開並加入專案時，程式碼組織可能會開始變得混亂，測試速度會慢一些。這種增長通常最終會出現難以維護的義大利麵條程式碼庫，每次開發人員重構資料模型時都會需要複雜的遷移計劃。
大型軟體專案通常需要幾年時間才能成熟，然後它們慢慢開始變成難以理解的混亂，難以維護。專案的開發人員夢想著用最新的框架從頭開始構建應用程式。通過這樣做，他們通常會再次遇到同樣的問題 - 重複同樣的故事。
將應用程式拆分為單獨的部分，即使生成的程式碼仍將在單個程序中執行。開發人員通過使用外部庫和框架構建應用程式來實現此目的。這些工具可以是內部工具，也可以來自開源軟體（OSS Open Source Software）社群。
如果使用像Flask這樣的框架，用Python構建Web應用程式，可以讓您專注於業務邏輯，並使得將一些程式碼外部化為Flask擴充套件和小型Python包非常有吸引力。將程式碼拆分為小包通常是控制應用程式增長的好主意。
例如，酒店預訂應用程式中的PDF生成器可以是一個單獨的Python包，它使用Reportlab和一些模板來完成工作。有可能這個包可以在其他一些應用程式中重用，甚至可能釋出到社群的Python包索引（Python Package Index PyPI）。
但是你仍在構建一個單獨的應用程式，並且仍然存在一些問題，例如無法以不同方式擴充套件，或者由錯誤依賴引入的其他問題。您甚至會遇到新的挑戰，因為您現在正在使用依賴。如果你的應用程式的一部分使用了庫，但是PDF生成器只能使用該庫的特定版本。
微服務實現
微服務會將程式碼組織到幾個單獨的元件中，這些元件在不同的程序中執行。
圖片.png
元件列表
- 預訂UI：前端服務，它生成Web使用者介面，並與所有其他微服務互動。
- PDF報告服務：非常簡單的服務，可以為收據或給定模板和某些資料的任何其他文件建立PDF。
- 搜尋：可以查詢的服務，以獲取給定城市名稱的酒店列表。該服務有自己的資料庫。
- 付款：與第三方銀行服務互動並管理開票資料庫的服務。它還會發送成功付款的電子郵件。
- 預訂：儲存預訂，並生成PDF。
- 使用者：儲存使用者資訊，並通過電子郵件與使用者互動。
- 身份驗證：基於OAuth 2的服務，返回身份驗證令牌，每個微服務都可以在呼叫其他令牌時進行身份驗證。
每個元件使用HTTP協議進行通訊，並通過RESTful Web服務提供介面
。
沒有集中式資料庫，因為每個微服務在內部處理自己的資料結構，而進出的資料使用JSON等語言無關的格式。它可以使用XML或YAML，只要它可以由任何語言生成和使用，並通過HTTP請求和響應傳播。
Booking UI服務有點特別，因為它生成使用者介面（UI）。根據用於構建UI的前端框架，如果介面使用基於JavaScript的靜態客戶端工具直接在瀏覽器中生成介面，則Booking UI輸出可以是HTML和JSON的混合，甚至是簡單的JSON。
微服務是專注於特定任務，是輕量級的應用程式，它提供了縮小的功能列表，具有明確定義的合同。它是單一責任的元件，可以獨立開發和部署。
另外可以考慮將基於UDP的小型服務等作為微服務交換二進位制資料。本書中，我們所有的微服務是使用HTTP協議的簡單Web應用程式，並且當它不是UI時使用和生成JSON。
微服務的好處
- 更加專注
- 小專案，更簡單
- 更多擴充套件和部署選項
微服務的陷阱
- 不合邏輯的分割
過早分割是萬惡之源。
- 更多的網路訊息
- 資料儲存和分片
在保持微服務獨立的同時儘可能避免資料重複是設計基於微服務的應用程式的最大挑戰之一。
-
相容性問題
-
測試