關於Python構建微服務的思考（一）

一：什麼是微服務？

　　微服務是一種架構風格，一個大型複雜軟件應用由一個或多個微服務組成。 系統中的各個微服務可被獨立部署，各個微服務之間是鬆耦合的。 每一個微服務僅關注於完成一件任務並很好地完成該任務。 在全部狀況下，每一個任務表明着一個小的業務能力。

　　固然啦，關於微服務還有不少種定義，並無一個官方的標準，一般在解釋微服務的時候，一般會提起一種面向服務的架構——SOA，其核心的原則就是將應用組織成一獨立的功能單元，可遠程訪問並單獨進行操做和更新，簡單來講，就是每一個單元都是一個獨立的服務，它能夠實現業務的一個方面，並經過接口提供功能，雖然SOA清楚地指出服務應當是獨立的進程，可是並未強制使用哪一種協議進行交互，對於部署和配置仍是至關模糊的，SOA服務能夠在同一個機器上使用socket經過IPC（進程間通訊）方式進行交互，若要使用內存共享，間接消息隊列或遠程過程調用（RPC），這是一個很是普遍的定義，只要沒用在單個進程中運行全部應用，SOA能夠是任何東西。

二：傳統的單體架構

　　舉例來講：一個商城，除了要有靜態的HTML內容外，還必需要有相關的模塊，好比用戶模塊，訂單模塊，商品模塊，優惠券模塊等等，當用戶對應用進行操做的時候，會伴隨着針對數據庫的一些SQL操做，而後再通過渲染返回給HTML的頁面，整過過程都至關於在一個應用的總體內進行，較少的對外部服務進行網絡請求（好比註冊時須要請求第三方短信驗證），在經典的LAMP架構中，每一個傳入的請求都會在數據庫生成關聯的SQL查詢，而後服務器再使用模板引擎生成相應的HTML進行響應。

這種架構有很明顯的優缺點，優勢就是：1.咱們能夠很容易的開始一個項目；2.簡化了數據的設計和組織；3.部署應用也會相對簡單

但他也有很明顯的缺點：1.咱們若是想增長一些功能的時候，修改代碼可能會影響到原來不相關的功能，對某部分代碼的錯誤修改可能致使整個應用的崩潰

　　　　　　　　　　　2.擴展應用的解決方案存在的限制：可部署多個實例，但若期中一個特定的功能佔用了全部資源，則會影響整個應用

　　　　　　　　　　　3.隨着應用的迭代，代碼庫的增加，很難保證代碼的乾淨和可控性。

 

 三.微服務架構

以下圖所示：

 

如上圖所示，這些微服務，諸如電子郵件的外部服務，將提供和單體應用相同的功能集，這個架構中的每一個 組件都使用HTTP協議進行通訊，拖過REST風格的web接口提供服務，每一個微服務都在內部處理本身的數據結構，不須要中心化數據庫，使用廣泛的數據格式如JSON輸入輸出數據，任何語言均可生成和使用，最後經過HTTP請求和響應進行傳輸。整體來講，微服務是一個輕量級的應用，它能夠經過良好的契約提供一組有限的功能，它是具備單一責任的組件，可獨立開發和部署。

微服務架構的優勢：

1.分離開發團隊的注重點，每一個微服務均可由一個團隊獨立開發，每一次版本迭代只會在服務的內部進行，不會影響其餘的應用，低耦合的開發模式，加快項目的進程。

2.若是在現成的微服務應用中進行跨越式的迭代，好比說更換語言和框架，咱們能夠把它隔離在一個微服務中，使用獨立的數據庫，讓一小部分用戶去試驗這個方案，從而不影響整個應用的運行

3.更加靈活的擴展與部署，根據微服務的定義，咱們能夠將服務部署在不一樣性能的服務器上面，須要消耗CPU的放在性能優良的服務器上面，只消耗內存的（如Redis這種內存數據庫）咱們能夠部署在CPU稍微較差，而內存較大的服務器上，從而減小了部署的成本

有好確定有壞：

1.微服務若出現不合理的拆分，當你重構一些業務邏輯時，你的代碼就會讓你搔首踟躕了，嘻嘻，若是你要實現一些功能，老是要部署兩個微服務，或者你改變了一個微服務總會影響另外一個數據模型時，你就該考慮合併兩個微服務了

2.在微服務的構建過程當中，使用了不少的網絡交互，這也帶來了問題，若有因爲網絡隔離或服務延遲，「商城HTML」沒法及時調用相關的服務，這會產生嚴重的後果

3.假如用戶添加的系統中來，進行某些數據操做時，是否是須要同步每個服務，這樣作會不會產生冗餘呢，保持微服務的隔離的同時又要儘可能避免數據的重複

4.兼容性的問題，可能會出現版本的不一致

5.測試上的問題，衆所周知，產品要部署上線時確定要通過相應的測試，可是微服務架構是一個分離的架構，不一樣於單體架構，他須要相應的工具才能進行測試，這也是限制微服務開發的一個難題。