從零開始學習微服務架構(一)

時間 2019-11-10

標籤開始學習微服架構欄目系統架構简体版

原文原文鏈接

　　做爲一名IT從業者，懈怠是一件奢侈的事情，由於在IT圈，原地踏步就等於退步。前端

　　「微服務」這個名詞已經廣爲流傳，可是我以爲大部分的人也許同我同樣，僅僅只是處於對這個概念的認知上；是的！今天我但願跟你們一塊兒揭開它的神祕面紗:)web

　　本次系列文章主要是記錄本身一點一點學習微服務的過程，但願你們能和我一塊兒探討或者指正不足［抱拳］。算法

咱們爲何要使用微服務架構

　　在我從事架構師的這幾年，我帶領團隊作過不少項目，以小中型爲主，不多涉及大型項目，所以我設計的架構每每都是單體式應用，如下架構拓撲圖是我最經常使用的： spring

　　對於不一樣項目性能需求，經過橫向擴展服務器數量基本上能夠達到。緩存

　　其實上圖的架構就是一個通用典型單體架構，應用核心是業務邏輯，有API網關和Service業務模塊構成，前端經過Nginx負載均衡對外提供Web服務或者REST API服務。tomcat

　　儘管也是模塊化邏輯，可是最終它仍是會被打包成War並部署爲單體式應用。經過多個tomcat來橫向擴展訪問瓶頸，很是簡單易用，也基本上解決了我工做中的多數項目問題～服務器

　　那麼問題來了，這種架構到底有什麼問題？架構

從開發角度來說：假如我要修改某一點業務（好比工資結算的一個算法優化），那麼我修改完這個class後，須要把這個web工程從新編譯並打包；
從部署角度來說：一句代碼的修改，須要講全部的服務器從新替換war後部署一遍；
從測試角度來說：咱們不但須要作變動業務的測試，咱們還須要作各類迴歸測試，咱們不肯定這個方法的改動或者這個變量的改動，會不會對其餘方法或者class產生影響，因此咱們須要作全面的測試，即便只修改了一句代碼。

　　我相信大多數人可能遇到過這樣的問題：咱們要接手修改離職的同事寫的代碼，複雜的業務邏輯，混亂的命名規則看的腦殼疼，有時候爲了修改一個bug，咱們花了幾天的時間才捋順了邏輯，到了最後可能就修改了一兩句代碼，這個工做很耗時，情緒也很很差，代碼變得愈來愈難以維護。負載均衡

　　另外，在現在互聯網的時代，敏捷開發，快速迭代，持續發開已經成爲一種常態，然而這些新特性在單體式應用上很難實現；因此若是你要處理相對大型的，複雜的業務，那麼從如今開始學習微服務架構吧！框架

什麼是微服務架構？

　　Martin Folwer對微服務架構的定義是：

　　［微服務架構是一種架構模式，它提倡將單一應用程序劃分紅一組小的服務，服務之間互相協調、互相配合，爲用戶提供最終價值。每一個服務運行在其獨立的進程中，服務與服務間採用輕量級的通訊機制互相協做（一般是基於HTTP協議的RESTful API）。每一個服務都圍繞着具體業務進行構建，而且可以被獨立的部署到生產環境、類生產環境等。另外，對具體的服務而言，應根據業務上下文，選擇合適的語言、工具對其進行構建。］

　　［敲黑板］在這裏有一個很大的概念誤區（起碼我之前是混淆的）：「微服務」和「微服務」架構，這是兩個不一樣的概念，他們有着本質的區別：「微服務」強調的是服務的大小，它關注的是某一個點，而「微服務架構」是一種架構思想，須要從總體上對軟件系統進行考量。我以前曾經看過一段頗有名的評論：

　　［Chris Richardson說：「 微服務」是一個很糟糕的名字，它致使開發人員建立了許多粒度很小的服務，每一個服務擁有一個單獨的REST端點。不只如此，這個名字還暗示了微服務在開發者心目中的重要位置。例如，人們會說「咱們能夠用微服務來解決這個問題」；我也看到了愈來愈多的「某某微服務框架」，而實際上，這些框架跟微服務架構不必定有太多聯繫，它們只是簡單的Web框架（如：spring-boot）。使用「微服務架構」這個名字會更恰當些。它是一種架構風格，它把一系列協做的服務組織成一個系統來支撐業務。］

OK，當咱們理解了什麼是微服務架構以後，咱們再來從新分析一下我上面的那個單體式應用架構圖，我對它作了一些修改：

　　我將原來的一個很大的複雜war包拆成了一系列的簡單的應用，每一個應用只關注本身的業務：好比，對於手機用戶，對於pc用戶不一樣用戶，設備和特殊場景，都分別部署不一樣的應用服務。

　　每個後臺服務開放一個REST API，好比API1，API2...n，外界同API不能直接進行交互，須要經過API網關來傳遞消息。API網關負責負載均衡，緩存，ACL，計費，監控等等。

　　不一樣的服務之間，好比API1和API2之間也會有訪問與被訪問的關係，咱們在後續章節再討論這部分。