微服務與docker關係介紹

因公司業務市場的發展與技術架構等結合因素，希望接下來的產品架構能支撐輕量級、高併發、大資料、智慧化、易維護、動態擴充套件等方向發展，這段時間參與我們公司架構研發部等一起負責架構研發等相關工作，從中開始學習微服務、docker、非功能設計相關技術，公司使用Spring Boot、Spring Cloud、Docker和Netflix、Kubernetes、Prometheus等開源工具來構建與監控微服務，在團隊中我主要負責工作內容是CaaS平臺&devops建設，目前主要負責框架的效能診斷分析優化工作，後期主要工作內容：主機環境搭建管理、環境標準化、微服務跨主機通訊支援、微服務動態擴容和縮容、微服務可用性監控、自動化部署運維規範、微服務基礎映象設計、效能測試與調優等非功能性技術工作，雖然才開始介入事件，但是也從公司的資深架構專家和他團隊人員介紹，慢慢了解微服務與

備註：測試微服務應用程式也更復雜。服務類似的測試類將需要啟動該服務及其所依賴的任何服務，服務之間的通訊介面技術性測試要求多一些，而且在非功能測試技術要求工藝更加複雜，軟硬體的配置合理性、有效性、資源利用的充分性等監控要求更高。

微服務與傳統服務區別簡易介紹

傳統的WEB應用核心分為業務邏輯、介面卡以及API或通過UI訪問WEB介面。其業務邏輯定義業務流程、業務規則以及各領域實體。而其介面卡包括資料庫訪問元件、訊息元件以及訪問介面等，類似打車軟體、叫餐軟體。儘管也是遵循模組化開發，但最終它們會打包並部署為單體式應用居多。例如Java應用程式會被打包成WAR，部署在Tomcat

·          1、部署不靈活：構建時間長，任何小修改必須重新構建整個專案；

·          2、穩定性不高：一個物件記憶體釋放不及時等問題，可能會導致整個應用掛掉；

·          3、擴充套件性不夠：高併發情況下的業務需求，在擴充套件性方面比較麻煩；

所以，現在主流的設計一般會採用微服務架構。其思路不是開發一個巨大的單體式應用，而是將應用分解為小的、互相連線的微服務，每個業務邏輯都被分解為一個微服務，微服務之間通過REST API通訊。一些微服務也會向終端使用者或客戶端開發API介面。但通常情況下，這些客戶端並不能直接訪問後臺微服務，而是通過

微服務優點，比傳統的應用程式更有效地利用計算資源。這是因為它們通過擴充套件元件來處理功能瓶頸問題。

  • 一種軟體架構模式

   • 複雜應用解耦為小而眾的服務

   • 各服務精而專

   • 服務間通訊通過API完成

   • 更快且更容易更新

而為了滿足如上幾大優點或者說規則微服務細化帶來工作維護麻煩性等，一般使用docker技術結合來提供微服務的優勢和運維工作的高效性。

微服務與docker關係

      Docker 是一個開源應用容器（當然目前也分為CE和EE版本，不完全開源化，也存在收費版本），讓開發者可以打包他們的應用以及依賴包到一個可移植的容器中，然後釋出到任何流行的 Linux 機器上，也可以實現虛擬化。容器是完全使用沙箱機制，相互之間不會有任何介面。

       Docker 作為容器工具可以把：業務邏輯容器、資料庫容器、儲存容器、佇列容器使得軟體可以拆分成若干個標準化容器，然後像搭積木一樣組合起來，讓彼此通訊，從而形成微服務。

​       因此微服務很適合用 Docker 容器實現，每個容器承載一個服務。一臺計算機同時執行多個容器，從而就能很輕鬆地模擬出複雜的微服務架構.