微服務架構

微服務的誕生並非偶然，它是在網際網路高速發展，技術日新月異的變化以及傳統架構無法適應快速變化等多重因素的推動下誕生的產物。網際網路時代的產品通常有兩類特點：需求變化快和使用者群體龐大，在這種情況下，如何從系統架構的角度出發，構建靈活、易擴充套件的系統，快速應對需求的變化;同時，隨著使用者的增加，如何保證系統的可伸縮性、高可用性，成為系統架構面臨的挑戰。

如果還按照以前傳統開發模式，開發一個大型而全的系統已經很難滿足市場對技術的需求，這時候分而治之的思想被提了出來，於是我們從單獨架構發展到分散式架構，又從分散式架構發展到 SOA 架構，服務不斷的被拆分和分解，粒度也越來越小，直到微服務架構的誕生。

微服務架構是 SOA 架構的傳承，但一個最本質的區別就在於微服務是真正的分散式的、去中心化的。把所有的“思考”邏輯包括路由、訊息解析等放在服務內部，去掉一個大一統的 ESB，服務間輕通訊，是比 SOA 更徹底的拆分。微服務架構強調的重點是業務系統需要徹底的元件化和服務化，原有的單個業務系統會拆分為多個可以獨立開發，設計，執行和運維的小應用，這些小應用之間通過服務完成互動和整合。

大約 2009 年開始，Netflix 完全重新定義了它的應用程式開發和操作模型，拉開了微服務探索的第一步，直到2014年3月 Martin Fowler 寫的一篇文章 Microservices 以更加通俗易懂的形式為大家定義了什麼是微服務架構。Martin Fowler 在文中闡述了對微服務架構的設想，認為微服務架構是一種架構模式，它提倡將單一應用程式劃分成一組小的服務，服務之間互相協調、互相配合，為使用者提供最終價值。

每個服務執行在其獨立的程序中，服務和服務間採用輕量級的通訊機制互相溝通(通常是基於 HTTP 的 RESTful API)。每個服務都圍繞著具體業務進行構建，並且能夠被獨立地部署到生產環境、類生產環境等。另外，應儘量避免統一的、集中式的服務管理機制，對具體的一個服務而言，應根據業務上下文，選擇合適的語言、工具對其進行構建。

微服務架構和資料治理

隨著微服務架構的落地，人們發現微服務架構雖然改進了開發模式，但同時也引入了一些問題，在這所有的問題中，最重要的也是馬上要面臨的一個問題就是資料的問題。在微服務架構中我們強調徹底的元件化和服務化，每個微服務都可以獨立的部署和投產，其實也就意味著很多的微服務有自己獨立的資料庫。

整個業務資料被分散在各個子服務之後會帶來兩個最明顯的問題：1、業務管理系統對資料完整的查詢，比如分頁查詢、多條件查詢等，資料被割裂後如何來整合?2、如何對資料進一步的分析挖掘?這些需求可能需要分析全量的資料，並且在分析時不能影響到當前業務。

從技術方案來講，我們一般有兩種選擇來處理這些問題，第一種是線上處理資料，第二種是離線處理資料。

線上處理資料的方案就是按照微服務的標準介面來進行，後端需要哪個系統的資料就去呼叫某個微服務提供的介面來獲取。後端管理平臺根據前端的需求去不同的微服務系統去獲取資料，然後將返回的資料進行處理後將資料返回。這種方案有兩個弊端：1)一方面微服務資料方需要提供資料介面，一方面資料的使用者需要去寫呼叫方法，並且呼叫者需要編寫大量的程式碼進行資料處理;2)在對各個微服務進行調取資料時會影響微服務的正常業務處理效能。

離線處理資料方案，就是將業務資料準實時的同步到另外一個數據庫中，在同步的過程中進行資料整合處理，以滿足業務方對資料的需求，資料同步過來後，再提供另外一個服務介面專業負責對外輸出資料資訊。這種方案有兩個特點：1)資料同步方案是關鍵，技術選型有很多，如何選擇切合公司業務的技術方案;2)離線資料處理對微服務正常業務處理沒有影響。

在我以往的工作中兩種方案都實施過，個人更傾向於使用第二種方案。

MongoDB 和資料分析

MongoDB 稱之為對開發人員最友好的資料庫，不再強調傳統關係資料庫中的行和列，整個表可以看作一個 Json 文件，MongoDB 也被認為在 Nosql 中最像關係資料庫的 Nosql 資料庫，保留了類似關係資料庫的資料庫(DataBase)、集合(Collection)、文件物件(Document)。

MongoDB 是目前最熱門非關係資料庫的之一，在最新的資料庫排行榜中 MongoDB 排名第五，在所有的非關係資料庫中排名第一，非常廣泛的應用於國內外的網際網路公司。

MongoDB 最大的特點是支援的查詢語言非常強大，其語法有點類似於面向物件的查詢語言，幾乎可以實現類似關係資料庫單表查詢的絕大部分功能，而且還支援對資料建立索引。MongoDB 在高可用和讀寫負載均衡上的實現非常簡潔和友好，MongoDB 自帶了副本集的概念，通過設計恰當的副本集和驅動程式，可以非常便地實現高可用、讀寫負載均衡。

MongoDB 的這些特性非常方便對資料進行高效能查詢，MongoDB 支援 Aggregate 和 Mapreduce 利用分而治之的理念來處理大規模資料分析。Spring Boot 對 MongoDB 的支援非常友好，使用 Spring Boot 非常便利的處理對 MongoDB 查詢和操作，Spring Boot 也提供了元件包來支援對 MongoDB的使用。

MongoDB 4.0 宣佈將正式支援 ACID 事務，未來 MongoDB 的想象空間更加巨大!因此 MongDB + Spring Boot 是微服務架構中資料分析的理想選擇之一。

再來聊聊 Spring Boot

Spring Boot 是由 Pivotal 團隊提供的全新框架，其設計目的是用來簡化新 Spring 應用的初始搭建以及開發過程。該框架使用了特定的方式來進行配置，從而使開發人員不再需要定義樣板化的配置。採用 Spring Boot 可以大大的簡化開發模式，所有你想整合的常用框架，它都有對應的元件支援。

Spring Boot 基於 Spring 開發，Spirng Boot 本身並不提供 Spring 框架的核心特性以及擴充套件功能，只是用於快速、敏捷地開發新一代基於 Spring 框架的應用程式。也就是說，它並不是用來替代 Spring 的解決方案，而是和 Spring 框架緊密結合用於提升 Spring 開發者體驗的工具。同時它集成了大量常用的第三方庫配置(例如 Redis、MongoDB、Jpa、RabbitMQ、Quartz 等等)，Spring Boot 應用中這些第三方庫幾乎可以零配置的開箱即用，大部分的 Spring Boot 應用都只需要非常少量的配置程式碼，開發者能夠更加專注於業務邏輯。

Spring Boot 一經推出就受到開源社群的追捧，Spring Boot 官方提供了很多 Starters 方便整合第三方產品，很多主流的框架也紛紛進行了主動的整合，比如 Mybatis。Spring 官方非常重視 Spring Boot 的發展，在 Spring 官網首頁進行重點推薦介紹，是目前 Spring 官方重點發展的專案之一。

Spring Boot 本身發展特別快，自從 2014 年 4 月釋出 Spring Boot 1.0 之後，版本更新非常頻繁，我在 2016 年使用的時候是 1.3.X，到現在 Spring Boot 已經發布了 Spring Boot 2.0，Spring Boot 2.0 集成了很多最新優秀的技術和新特性，並且對 Spring Boot 1.0 的 API 進行了大幅優化。Spring Boot 一經推出就迅速的成為一門熱門的技術，從下圖也可以看出這個結論：

上圖為2014年到2018年 Spring Boot 的百度指數，可以看出 Spring Boot 2.0 的推出引發了搜尋高峰。

Spring Boot 和 微服務架構

隨著 Spring 不斷的發展，涉及的領域越來越多，專案整合開發需要配合各種各樣的檔案，慢慢變得不那麼易用簡單，違背了最初的理念，甚至人稱配置地獄。Spring Boot 正是在這樣的一個背景下被抽象出來的開發框架，目的為了讓大家更容易的使用 Spring 、更容易的整合各種常用的中介軟體、開源軟體;另一方面，Spring Boot 誕生時，正處於微服務概念在慢慢醞釀中，Spring Boot 的研發融合了微服務架構的理念，實現了在 Java 領域內微服務架構落地的技術支撐。

Spring Boot 作為一套全新的框架，來源於 Spring 大家族，因此 Spring 所有具備的功能它都有，而且更容易使用;Spring Boot 以約定大於配置的核心思想，預設幫我們進行了很多設定，多數 Spring Boot 應用只需要很少的 Spring 配置。Spring Boot 開發了很多的應用整合包，支援絕大多數開源軟體，讓我們以很低的成本去整合其他主流開源軟體。

Spring Boot 特性：

• 使用 Spring 專案引導頁面可以在幾秒構建一個專案
• 方便對外輸出各種形式的服務，如 REST API、WebSocket、Web、Streaming、Tasks
• 非常簡潔的安全策略整合
• 支援關係資料庫和非關係資料庫
• 支援執行期內嵌容器，如 Tomcat、Jetty
• 強大的開發包，支援熱啟動
• 自動管理依賴
• 自帶應用監控
• 支援各種 IED，如 IntelliJ IDEA 、NetBeans

Spring Boot 的這些特性非常方便、快速構建獨立的微服務。所以我們使用 Spring Boot 開發專案，會給我們傳統開發帶來非常大的便利度，可以說如果你使用過 Spring Boot 開發過專案，就不會再願意以以前的方式去開發專案了。

總結一下，使用 Spring Boot 至少可以給我們帶來以下幾方面的改進：

• Spring Boot 使編碼變簡單，Spring Boot 提供了豐富的解決方案，快速整合各種解決方案提升開發效率。
• Spring Boot 使配置變簡單，Spring Boot 提供了豐富的 Starters，整合主流開源產品往往只需要簡單的配置即可。
• Spring Boot 使部署變簡單，Spring Boot 本身內嵌啟動容器，僅僅需要一個命令即可啟動專案，結合 Jenkins 、Docker 自動化運維非常容易實現。
• Spring Boot 使監控變簡單，Spring Boot 自帶監控元件，使用 Actuator 輕鬆監控服務各項狀態。

總結，Spring Boot 是 Java 領域最優秀的微服務架構落地技術，沒有之一。

三者之間的糾葛

瞭解完微服務架構、Spring Boot、大資料治理之後，我們就發現這樣一個有趣的事情：微服務架構是一種架構思想，是架構不斷髮展的必然結果，具有構建靈活、易擴充套件、快速應用、可伸縮性、高可用等特點;微服務架構思想的推出對技術有了更高的要求，在這樣的背景下 Spring Boot 孕育而生，Spring Boot 出生名門，從一開始就站在一個比較高的起點，又經過這幾年的發展，生態足夠完善，Spring Boot 已經當之無愧成為 Java 領域最熱門的技術。

微服務架構下，資料被分隔到 N 個獨立的微服務中，如何應對市場、業務對大量資料的查詢、分析就變的非常急迫，利用 Spring Boot 和 MongoDB 可以輕鬆的解決這個問題，通過技術手段將分裂到 N 個微服務的資料同步到 MongoDB 叢集中，在同步的過程中進行資料清洗，來滿足公司的各項業務需求。Spring Boot 對 MongoDB 的支援非常友好，一方面 Spring Data 技術預生成很多常用方法便於使用，另一方面 Spring Boot 封裝了分散式計算的相關函式，可以讓我們以較簡潔的方式來實現統計查詢。

Spring Boot 是 Java 領域微服務架構最優落地技術，Spring Boot+MongoDB 方案是在微服務架構下資料治理的最佳方案之一。

當然如果我們對微服務架構、Spring Boot 、MongoDB 不熟悉的話，可能需要走很多的彎路。錯誤的技術方案會對後期的微服務落地帶來非常大的困擾，增加額外的開發工作量，我自己深有體會，合適的技術方案可以節省60%