作為一名IT從業者，懈怠是一件奢侈的事情，因為在IT圈，原地踏步就等於退步。
“微服務”這個名詞已經廣為流傳，但是我覺得大部分的人也許同我一樣，僅僅只是處於對這個概念的認知上；是的！今天我希望跟大家一起揭開它的神秘面紗:)
本次系列文章主要是記錄自己一點一點學習微服務的過程，希望大家能和我一起探討或者指正不足［抱拳］。
-
我們為什么要使用微服務架構
在我從事架構師的這幾年，我帶領團隊做過很多項目，以小中型為主，很少涉及大型項目，因此我設計的架構往往都是單體式應用，以下架構拓撲圖是我最常用的：
對於不同項目性能需求，通過橫向擴展服務器數量基本上可以達到。
其實上圖的架構就是一個通用典型單體架構，應用核心是業務邏輯，有API網關和Service業務模塊構成，前端通過Nginx負載均衡對外提供Web服務或者REST API服務。
盡管也是模塊化邏輯，但是最終它還是會被打包成War並部署為單體式應用。通過多個tomcat來橫向擴展訪問瓶頸，非常簡單易用，也基本上解決了我工作中的多數項目問題～
那么問題來了，這種架構到底有什么問題？
- 從開發角度來講：假如我要修改某一點業務（比如工資結算的一個算法優化），那么我修改完這個class后，需要把這個web工程重新編譯並打包；
- 從部署角度來講：一句代碼的修改，需要講所有的服務器重新替換war后部署一遍；
- 從測試角度來講：我們不但需要做變更業務的測試，我們還需要做各種回歸測試，我們不確定這個方法的改動或者這個變量的改動，會不會對其他方法或者class產生影響，所以我們需要做全面的測試，即使只修改了一句代碼。
我相信大多數人可能遇到過這樣的問題：我們要接手修改離職的同事寫的代碼，復雜的業務邏輯，混亂的命名規則看的腦袋疼，有時候為了修改一個bug，我們花了幾天的時間才捋順了邏輯，到了最后可能就修改了一兩句代碼，這個工作很耗時，情緒也很不好，代碼變得越來越難以維護。
另外，在如今互聯網的時代，敏捷開發，快速迭代，持續發開已經成為一種常態，然而這些新特性在單體式應用上很難實現；所以如果你要處理相對大型的，復雜的業務，那么從現在開始學習微服務架構吧！
-
什么是微服務架構？
Martin Folwer對微服務架構的定義是：
［微服務架構是一種架構模式，它提倡將單一應用程序划分成一組小的服務，服務之間互相協調、互相配合，為用戶提供最終價值。每個服務運行在其獨立的進程中，服務與服務間采用輕量級的通信機制互相協作（通常是基於HTTP協議的RESTful API）。每個服務都圍繞着具體業務進行構建，並且能夠被獨立的部署到生產環境、類生產環境等。另外，對具體的服務而言，應根據業務上下文，選擇合適的語言、工具對其進行構建。］
［敲黑板］在這里有一個很大的概念誤區（起碼我以前是混淆的）：“微服務”和“微服務”架構，這是兩個不同的概念，他們有着本質的區別：“微服務”強調的是服務的大小，它關注的是某一個點，而“微服務架構”是一種架構思想，需要從整體上對軟件系統進行考量。我之前曾經看過一段很有名的評論：
［Chris Richardson說：“
微服務”是一個很糟糕的名字，它導致開發人員創建了許多粒度很小的服務，每個服務擁有一個單獨的REST端點。不僅如此，這個名字還暗示了微服務在開發者心目中的重要位置。例如，人們會說“我們可以用微服務來解決這個問題”；我也看到了越來越多的“某某微服務框架”，而實際上，這些框架跟微服務架構不一定有太多聯系，它們只是簡單的Web框架（如：spring-boot）。使用“微服務架構”這個名字會更恰當些。它是一種架構風格，它把一系列協作的服務組織成一個系統來支撐業務。］
我將原來的一個很大的復雜war包拆成了一系列的簡單的應用，每個應用只關注自己的業務：比如，對於手機用戶，對於pc用戶不同用戶，設備和特殊場景，都分別部署不同的應用服務。
每一個后台服務開放一個REST API，比如API1，API2...n，外界同API不能直接進行交互，需要通過API網關來傳遞消息。API網關負責負載均衡，緩存，ACL，計費，監控等等。
不同的服務之間，比如API1和API2之間也會有訪問與被訪問的關系，我們在后續章節再討論這部分。
-
本章總結
對比我的第一張架構圖和第二張架構圖，我認為從架構演變來說，有以下幾點：
- 圖1的所有服務出口單一，圖2服務出口有多個，根據設備的不同，需求的不同，可以分離維多個出口；
- 圖1的業務是集合的，只能通過復制備份的方式橫向擴展，圖2業務是非耦合的，盡可能在單一服務中處理單一集中性業務，不摻雜其他無關業務；
- 圖1代碼修改后，需要把所有服務器重新部署一遍；圖2只需要針對性的部署修改的具體服務，其他無關服務不需要變化。
好了，由於篇幅關系，今天我們就討論到這里，歡迎大家討論和建議；如果感興趣的話，請關注后續文章：）
以上。