一、服務架構設計與發展

1、單體架構

單體架構的特點和好處：

• 單一程式碼庫、IDE友好、看著簡單
• 容易部署
• 開發模型簡單，一份程式碼庫進行編碼、構建和部署
• 技術棧單一

單體架構的問題：

• 龐大的程式碼庫，關係錯綜複雜。
• 交付週期長。
• 擴充套件能力與彈性受限。
• 新技術與工具框架使用會受限。
• 維護成本高。
  

2、服務化架構：

服務化架構的特點和好處：

• 對業務進行分層，通常分為表現層（前段）、公共服務、業務邏輯服務、資料訪問層等。
• 對業務進行解耦，通過Pub-Sub或RPC進行伺服器間呼叫關係解耦。
• 服務獨立性，多數服務可以進行獨立打包釋出。
• 每個服務的技術棧單一。
• 部署簡單，具有可伸展性。

服務化架構的問題：

• 對於部分服務而言，程式碼庫依然很強大。
• 打包，釋出和部署流程不足夠好。
• 維護團隊間溝通受阻，技術經驗有效傳遞不夠。
• 服務增多對開發人員不夠友好。
  

3、微服務架構：

     服務註冊——>服務發現——>服務呼叫

4、架構設計發展：MVC Services（檢視、業務邏輯前後端分離）——>SOA（大型系統分層解耦，標準介面呼叫，分散式系統）——>Micro（雲端計算產物，關注敏捷互動和部署速度、頻次）

二、微服務簡介

• suite of small service：由一系列小服務組成。
• running in its own process：每個服務運行於自己的程序。
• built around business capabilities：圍繞著業務功能進行建模。
• independently deployable：每個服務可進行獨立部署。
• bare minimum of centralized managerment：最低限度集中管理。
  

1、微服務的特徵：

• 每個微服務都是業務完整的：介面及介面呈現、業務邏輯、資料管理。
• 每個微服務僅僅對一個業務負責：產品服務、評價服務、支付服務、訂單服務。
• 每個微服務介面明確定義：介面消費只關注介面，對微服務不具備依賴。
• 獨立部署、升級和伸縮。

2、微服務的獨立性關鍵詞：

• 程式碼庫獨立
• 技術棧獨立
• 可伸縮性、可擴充套件性獨立
• 業務功能獨立

3、獨立的程式碼庫：每個微服務具備自己的程式碼庫

• 由團隊開發者維護
• 編譯、打包、釋出及部署都很快
• 服務啟動迅速
• 在各個服務的程式碼庫間沒有交叉依賴

4、技術棧對立：每個微服務都有自己獨立的技術棧實現

• 根據業務實現需求來選擇最適合的需求棧
• 團隊可以嘗試新的技術、工具和框架
• 所選的技術一般來說都是輕量級
• 不需要同一標準化技術棧的選擇。無需關注因技術選型而糾結業務的實現

5、獨立的可伸縮性：每個微服務都可以獨立伸縮

• 更加直觀的定位效能的瓶頸
• 資料庫分片可根據需求來

6、業務功能獨立：每個微服務可以在不影響其他微服務的情況下進行功能擴充套件

• 例如更新新版本介面或者某個微服務中的某項功能時，無需更新整個系統
• 可以進行整個業務功能的重寫，並替換之

7、微服務的優點：

• 每個服務足夠內聚，足夠小，程式碼容易理解，開發效率高。
• 服務之間獨立部署，微服務架構讓持續部署成為可能。
• 每個服務可以各自進行x擴充套件和z擴充套件，而且每個服務可根據自己的需要部署到合適的硬體伺服器上。
• 容易擴大開發團隊，可以針對每個服務元件自己的開發團隊。
• 提高容錯性（fault isolation），一個服務的記憶體洩漏，並不會導致整個系統癱瘓。
• 系統不能被長期限制在某個技術棧。

8、微服務不足：

• 微服務應用是分散式系統，由此會帶來固有的複雜性，開發者需要在RPC或訊息傳遞之間選擇並完成程序間通訊機制。此外，他們必須用程式碼處理訊息傳遞過程中速度過慢或者不可用等區域性失效問題。
• 開發人員需要處理分散式系統的複雜性：開發人員需要設計服務間的通訊機制，對於需要多個後端服務的user case，要在沒有分散式事物的情況下，實現程式碼非常困難；設計多個服務直接的自動化測試也具備相當大的挑戰。
• 服務管理的複雜性：在生產環境要管理多個不同的服務例項，這意味著開發團隊要統一統籌。(PS：現在docker的出現適合解決這個問題)。

9、應用微服務架構的時機如何把握?

     對於業務還沒有理清楚、業務資料和處理能力還沒有開始爆發式增長之前的創業公司，不需要考慮微服務架構模式，這時候最重要的是快速開發、快速部署、快速試錯

三、微服務架構工作流程

• 設計階段：將產品功能拆分成若干個服務，為每個服務設計API介面。
• 開發階段：實現API介面（包括單元測試）實現UI原型（介面）。
• 測試階段：前後端整合，驗證產品功能。
• 部署階段：釋出測試環境，釋出開發環境。

四、Spring Boot介紹

1、為什麼使用springBoot?

• Spring Boot是為簡化Spring專案配置而生，使用它使得jar依賴管理以及應用編譯和部署更為簡單。Spring Boot提供自動化配置，使用Spring Boot，你只需編寫必要的程式碼和配置必須的屬性。

•   使用Spring Boot，只需20行左右的程式碼即可生成一個基本的Spring Web應用，並且內建了tomcat，構建的fat Jar包通過java -jar就可以直接執行。
  

• 如下特性使得Spring Boot非常契合微服務念，可以結合Spring Boot與Spring Cloud和Docker技術來構建微服務並部署到雲端：

• 一個可執行jar即為一個獨立服務

• 很容易載入到容器，每個服務可以在自己的容器（例如docker）中執行

• 通過一個指令碼就可以實現配置與部署，很適合雲端部署，並且自動擴充套件也更容易
  

2、springBoot有哪些特性？

•  spring-boot-starter-amqp通過spring-rabbit來支援AMQP協議（Advanced Message Queuing Protocol）。
  

•  spring-boot-starter-ws支援Spring Web Services。
  

•  spring-boot-starter-redis支援Redis鍵值儲存資料庫，包括spring-redis。
  

•  spring-boot-starter-test  支援常規的測試依賴，包括JUnit、Hamcrest、Mockito以及spring-test模組。

（2）獨立執行的Spring專案

       Spring Boot預設將應用打包成一個可執行的jar包檔案，構建成功後使用java -jar命令即可執行應用。或者在應用專案的主程式中執行main函式即可，不需要依賴tomcat、jetty等外部的應用伺服器。其中內建的servlet Container。此外，你仍然可以部署Spring Boot專案到任何相容Servlet3.0+的容器。
3、SpringBoot總結：

• 缺少註冊、發現等外圍方案

• 缺少外圍監控整合方案

• 缺少外圍安全管理方案

• 缺少REST落地的URI規劃方案

所以SpringBoot只是一個入門級的微框架