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

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

　　上一篇中，咱們已經籠統介紹了一下微服務，以及我在項目中是如何從傳統單體模式向微服務演變的。本章咱們深刻探討一下微服務的核心內容。

---

 

• 亂花漸欲迷人眼

　　　　當我剛剛開始接觸微服務的時候，我聽到了許多名次：「微服務」、「SOA」、「spring boot」、「spring cloud」、「docker」。面對這麼多名詞，一腦殼蒙圈～如今咱們來仔細理一理。

　　　　微服務：維基百科中是這麼定義的：微服務 (Microservices) 是一種軟件架構風格，它是以專一於單一責任與功能的小型功能區塊 (Small Building Blocks) 爲基礎，利用模組化的方式組合出複雜的大型應用程序，各功能區塊使用與語言無關 (Language-Independent/Language agnostic) 的 API 集相互通信。2014年，Martin Fowler 與 James Lewis 共同提出了微服務的概念，定義了微服務是由以單一應用程序構成的小服務，本身擁有本身的行程與輕量化處理，服務依業務功能設計，以全自動的方式部署，與其餘服務使用 HTTP API 通信。同時服務會使用最小的規模的集中管理 (例如 Docker) 能力，服務能夠用不一樣的編程語言與數據庫等元件實做。

　　　　SOA：維基百科中是這麼定義的：面向服務的體系結構（英語：service-oriented architecture）並不特指一種技術，而是一種分佈式運算的軟件設計方法。軟件的部分組件(調用者)，能夠經過網絡上的通用協議調用另外一個應用軟件組件運行、運做，讓調用者得到服務。SOA原則上採用開放標準、與軟件資源進行交互並採用表示的標準方式。所以應能跨越廠商、產品與技術。一項服務應視爲一個獨立的功能單元，能夠遠程訪問並獨立運行與更新，例如在在線線查詢信用卡帳單。

　　　　spring boot：Spring Boot是由Pivotal團隊提供的全新框架設計方式，其設計目的是用來簡化新Spring應用的初始搭建以及開發過程。它使用「習慣優於配置」的理念讓你的項目快速運行起來。所以Spring Boot並不能說是一個框架，而是一個集合或者工具。

　　　　spring cloud：百度百科中是這麼定義的：Spring Cloud是一系列框架的有序集合。它利用Spring Boot的開發便利性巧妙地簡化了分佈式系統基礎設施的開發，如服務發現註冊、配置中心、消息總線、負載均衡、斷路器、數據監控等，均可以用Spring Boot的開發風格作到一鍵啓動和部署。Spring Cloud並無重複製造輪子，它只是將目前各家公司開發的比較成熟、經得起實際考驗的服務框架組合起來，經過Spring Boot風格進行再封裝屏蔽掉了複雜的配置和實現原理，最終給開發者留出了一套簡單易懂、易部署和易維護的分佈式系統開發工具包。

　　　　docker：維基百科中是這麼定義的：Docker是一個開放源代碼軟件項目，讓應用程序佈署在軟件容器下的工做能夠自動化進行，藉此在Linux操做系統上，提供一個額外的軟件抽象層，以及操做系統層虛擬化的自動管理機制^[1]。Docker利用Linux核心中的資源分脫機制，例如cgroups，以及Linux核心名字空間（name space），來建立獨立的軟件容器（containers）。這能夠在單一Linux實體下運做，避免引導一個虛擬機形成的額外負擔。

---

 

　　從以上的各名詞解釋上來看，咱們能夠獲得以下幾個結論：

　　　　　1.微服務並非一個全新的框架，是一種軟件架構設計風格。

　　　　　2.微服務也屬於SOA，只是與傳統的SOA存在着一些差異。微服務能夠看做是SOA概念的昇華，微服務中對於業務拆分更加細粒度，微服務更傾向於去中心化，去ESB總線。

  3.Spring Boot和Spring Cloud組合，是開發微服務的一個黃金組合套裝。單並非說這兩個東西纔是微服務，只是咱們更習慣用這兩個套件來進行開發，咱們也同樣可使用其餘工具來開發微服務。

  4.Docker是一種容器，基於LXC實現的。Docker的抽象性和隔離性很是適合部署微服務。但也並非說只有Docker纔是微服務或者只有Docker才能部署微服務。咱們使用VM，甚至物理機同樣能夠部署微服務，只是從量級以及編排部署等方面考慮，使用Docker容器更容器部署和管理微服務。

• 微服務應用的四個設計原則

　　　　當咱們搞清楚了微服務所涉及到的一些概念以後，咱們也清楚的瞭解到了微服務的好處，那麼咱們能夠嘗試來把本身的應用設計成微服務了，而設計微服務應用，通常要遵循四個原則：

　　　　1.AKF拆分原則

　　　　　　

AKF擴展立方體(參考《The Art of Scalability》)，是一個叫AKF的公司的技術專家抽象總結的應用擴展的三個維度。理論上按照這三個擴展模式，能夠將一個單體系統，進行無限擴展。

X 軸 ：指的是水平復制，很好理解，就是講單體系統多運行幾個實例，作個集羣加負載均衡的模式。

Z 軸 ：是基於相似的數據分區，好比一個互聯網打車應用忽然或了，用戶量激增，集羣模式撐不住了，那就按照用戶請求的地區進行數據分區，北京、上海、四川等多建幾個集羣。

Y 軸 ：就是咱們所說的微服務的拆分模式，就是基於不一樣的業務拆分。

　　　　2.先後端分離

　　　　　　先後端分離並非什麼稀奇的東西了，作過APP的同窗確定都知道，先後端必然是分離的，在微服務中，不論是web仍是app，先後端都必須分離。

　　　　3.無狀態服務

在Java開發中，不少年前就有「有狀態bean」和「無狀態bean」，原理其實和微服務中的無狀態是相似的。通常應用系統中最常出現的有狀態：1.session問題；2.本地內存數據緩存；3.一些application級別的常量或者變量等。在微服務架構中，咱們要把這些有狀態的東西遷移到分佈式緩存中進行存儲，例如redis。

　　　　4.Restful通訊

　　　　　　restful在java web開發中已是很經常使用的設計風格了。

• 搭建微服務開發架構

　　　　如下架構圖是我在項目開發中設計的，以下圖所示：架構中所涉及到到具體組件，在後續博文中在單獨詳細介紹。

　　　　　　

 

1）web層採用Nginx+keepalived。keepalived經過虛擬VIP作Nginx負載，兩臺以上Nginx作高可用，同時經過Nginx反向代理Zuul集羣。實現高可用，高性能的web層。

2）網關層採用Netflix的Zuul組件。經過Zuul的攔截器實現用戶認證，權限管理，流量控制等操做；經過Zuul自帶的負載均衡Ribbon和斷路器Hystrix以及Zuul的反向代理功能，經過serviceId代理整個微服務集羣。

3）業務層根據基礎服務，支撐服務，核心業務三大層進行劃分，其中核心業務層前期可按照較粗粒度進行切分。全部服務之間經過REST API進行通訊，服務間經過斷路器Hystrix保證服務降級以及節點出現不可用狀態。

4）服務發現與註冊中心經過Eureka實現。作服務器端發現較好。

5）Session共享，身份認證經過集成redis+shiro來實現，可解決分佈式系統中Session共享、身份統一認證，權限控制等問題。

6）微服務監控經過Spring Admin集成斷路監控器Turbine來實現。鏈路監控可經過Zipkin聚合各業務通調用延遲數據。

7）配置文件中心經過spring cloud config實現，再配合spring cloud bus實現動態刷新。

8）以上架構圖中，並無體現DB，這是由於本項目的特殊性，DB採起了共享的方式（違背了微服務的原則:( ~），你們在設計時，應該每一個服務DB相互獨立進行設計比較好。

• 微服務持續集成架構設計

　　　　CI使用Jenkins+Git來實現，架構以下：

　　

• 微服務部署策略

　　　　微服務部署策略通常有以下3種方式：

1.單主機多服務實例模式

    提供一到多臺物理或虛擬主機，

    在每一個主機上運行多個服務實例。

　　1）一進程一服務：好比一個tomcat發佈一個服務

　　2）一進程多服務：好比一個tomcat發佈多個服務

優勢：資源利用相對高效；部署服務實例更快；

缺點：由於沒有隔離，會由於某個服務有問題致使整個主機異常

　　　　 

 2.單主機單服務實例模式

    每臺主機上運行獨立的服務實例。這一模式有兩種不一樣實現

——單虛擬機單服務實例和單容器單服務實例。

  1）單虛擬機單服務實例。

    把每一個服務大包圍一個虛擬機鏡像，

    相似 Amazon EC2 AMI每一個服務實例就是一臺使用

                               此鏡像啓動的虛擬機，譬如 EC2 實例。

 

  優勢：每一個服務實例徹底隔離運行，每一個實例都有固定的 CPU 和內存，

　　　　不會被別的服務佔用資源；

　　　　可以充分利用成熟的雲基礎設施；

  缺點：資源利用率低；

　　　　部署服務的新版本一般很緩慢。

　　　　大量無差異的沉重的工做。

　　　　

 

 2）單容器單服務實例。（Docker）

每一個服務實例運行在自有容器中。容器是操做系統級別的虛擬化機制。將服務快速打包爲docker鏡像，能夠在物理機或虛擬機上運行多個docker

  優勢：容器比VM更輕量級，服務徹底隔離，

　　　　打包和啓動速度更快；

　　　　容易監控資源；

  缺點：沒有虛擬機安全，由於共享了宿主機的操做系統；

　　　　管理容器鏡像是一項無差異的繁重工做。

 

　　在Docker日趨成熟的時代，固然仍是選擇第三種部署策略，基於Docker，但容器單服務方式。

---

 

• 本章總結

　　本章主要從整體架構角度對微服務整個設計到部署流程進行簡單探討，以後的章節再從開發角度對各個組件進行詳細討論。

　　好了，因爲篇幅關係，今天咱們就討論到這裏，歡迎你們討論和建議；若是感興趣的話，請關注後續文章：）

　　以上。