因公司業務市場的發展與技術架構等結合因素，希望接下來的產品架構能支撐輕量級、高並發、大數據、智能化、易維護、動態擴展等方向發展，這段時間參與我們公司架構研發部等一起負責架構研發等相關工作，從中開始學習微服務、docker、非功能設計相關技術，公司使用Spring Boot、Spring Cloud、Docker和Netflix、Kubernetes、Prometheus等開源工具來構建與監控微服務，在團隊中我主要負責工作內容是CaaS平臺&devops建設，我在團隊中是新手中的新手，目前主要負責框架的性能診斷分析優化工作，後期主要工作內容：主機環境搭建管理、環境標準化、微服務跨主機通信支持、微服務動態擴容和縮容、微服務可用性監控、自動化部署運維規範、微服務基礎鏡像設計、性能測試與調優等非功能性技術工作，雖然才開始介入事件，但是也從公司的資深架構專家和他團隊人員介紹，慢慢了解微服務與docker等關系和如何實施工作。（一個優秀的架構領導在團隊管理上，對技術的開放、共享、創新、執著、專業、容納百川等魅力體現，這段時間讓我深有感悟，也讓我能最短時間學習到新技術，還得繼續學習

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

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

傳統的WEB應用核心分為業務邏輯、適配器以及API或通過UI訪問WEB界面。其業務邏輯定義業務流程、業務規則以及各領域實體。而其適配器包括數據庫訪問組件、消息組件以及訪問接口等，類似打車軟件、叫餐軟件。盡管也是遵循模塊化開發，但最終它們會打包並部署為單體式應用居多。例如Java應用程序會被打包成WAR，部署在Tomcat。之間存在優缺，但是隨著市場的發展，用戶數、數據量、業務模式的增長，傳統模式存在一些缺點：

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

• 2、穩定性不高：一個對象內存釋放不及時等問題，可能會導致整個應用掛掉；

• 3、擴展性不夠：高並發情況下的業務需求，在擴展性方面比較麻煩；

所以，現在主流的設計一般會采用微服務架構。其思路不是開發一個巨大的單體式應用，而是將應用分解為小的、互相連接的微服務，每個業務邏輯都被分解為一個微服務，微服務之間通過REST API通信。一些微服務也會向終端用戶或客戶端開發API接口。但通常情況下，這些客戶端並不能直接訪問後臺微服務，而是通過API Gateway來傳遞請求。API Gateway一般負責服務路由、負載均衡、緩存、訪問控制和鑒權等任務。

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

? 一種軟件架構模式

? 復雜應用解耦為小而眾的服務

? 各服務精而專

? 服務間通信通過API完成

? 更快且更容易更新

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

微服務與docker關系

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

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

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

docker與微服務關系