資訊專欄INFORMATION COLUMN
筆者公司近年來基于SRE理念的運維模式決定一線運維們得有自己的運維場景提煉沉淀的運維支撐平臺。筆者公司基本在全國各地均有自己的運維團隊，這種情況下如果運維平臺使用單體架構，會導致在單體架構下跨地域，跨開發小組協調困難。因為業務團隊（運維團隊）分布全國各地并基于本地的實際需要，在一些通用場景的基礎上提出大量本地自己的運維場景實現需求，因為是全國性的SRE團隊，內部對應配備多個場景開發小組，基于單體架構會給各開發小組之間的協調和溝通帶來昂貴成本。所以，基于實際情況及業務場景需要，我們在相關產品選型初期就確定微服務架構，筆者今天就來講講微服務的相關入門知識。
●什么是微服務●
微服務一個相對較小且獨立的功能單元，是用戶可以感知的最小功能集，如一個網站有訂單管理、用戶管理、商品管理等模塊，我們就可以把其中的訂單管理、用戶管理做成微服務。
●微服務架構●
微服務架構風格是一種使用一套小服務來開發單個應用的方式突進，每個服務運行在自己的進程中，并且使用輕量級通信如HTTPAPI，這些服務基于業務能力構建，并能夠通過自動化部署機制來獨立部署，這些服務可以使用不同的編程語言，以及不同的數據儲存技術等。
●為什么使用微服務●
項目開始階段，運維場景功能并不是很齊全、體量小，單體架構可以滿足業務需要。但伴隨著業務能力拓展、自動化服務越來越集中，尤其是筆者公司希望給地場景能像貨幣一樣流通，單體架構會帶來一些問題：
復雜性逐漸變高
單體架構系統本身過于龐大和復雜，以至于任何一個開發者都很難以理解它的全部。這種極度的復雜度會形成惡性循環，由于代碼難以理解，因此開發人員更改更容易出錯，每一次更改系統更復雜、更難懂。
技術債務逐漸上升
隨著時間推移、需求變更和人員更迭，會逐漸形成應用程序的技術債務，并且越積越多。“不壞不修”，這在軟件開發中非常常見，在單體應用中，這種思想更嚴重。已使用的系統設計或代碼難以被修改，因為應用程序中的其他模塊可能會以意料之外的方式使用它。
部署速度逐漸變慢
隨著代碼的增多，構建和部署的時間也會增加。而在單體應用中，每次功能的變更或缺陷的修復都會導致重新部署整個應用，而且全量部署的方式耗時長、影響范圍大、風險高。
阻礙技術創新
單體應用往往使用統一的技術平臺或方案解決所有的問題，團隊中的每個成員必須使用相同的開發語言和框架，要想引入新框架或新技術平臺會非常困難。例如，一個使用Struts2構建的、有百萬行代碼的單體應用，如果想要換用SpringMVC，毫無疑問切換的成本是非常高的。
無法按需伸縮
單體應用只能作為一個整體進行擴展，無法根據業務模塊的需要進行伸縮。例如，應用中有的模塊是計算密集型的，它需要強勁的CPU；有的模塊則是IO密集型的，需要更大的內存。由于這些模塊部署在一起，不得不在硬件的選擇上做出妥協。
綜上，隨著業務需求的發展，功能的不斷增加，單體架構很難滿足互聯網時代快速變化的需要。
●使用微服務的優點與缺點●
優點如下：
易于開發和維護
微服務易于被一個開發人員理解，修改和維護，實現了模塊化的解決方案。
獨立部署啟動快
微服務架構模式是每個微服務獨立的部署，開發者不再需要協調其它服務部署對本服務的影響，這種改變可以加快部署速度。
技術棧不受限
這種架構使得每個微服務都可以有專門開發團隊來開發，開發者可以自由選擇開發技術，提供API服務。這種自由意味著開發者不需要被迫使用某項目開始時采用的過時技術，他們可以選擇現在的技術。甚至于，因為微服務都是相對簡單，即使用現在技術重寫以前代碼也不是很困難的事情。
按需伸縮
微服務架構模式使得每個微服務獨立擴展，你可以根據每個微服務的規模來部署滿足需求的規模。甚至于，你可以使用更適合于微服務資源需求的硬件。比如，你可以把依賴CPU計算能力的指標管理微服務部署在高配置的多核CPU實例上，把視頻管理模塊部署在高內存、I/O讀寫能力強的實例上。
缺點如下：
運維要求高
對于單體架構來講，我們只需要維護好這一個項目就可以了，但是對于微服務架構來講，由于項目是由多個微服務構成的，每個模塊出現問題都會造成整個項目運行出現異常，想要知道是哪個模塊造成的問題往往是不容易的，因為我們無法一步一步通過debug的方式來跟蹤，這就對運維人員提出了很高的要求。
分布式的復雜性
對于單體架構來講，我們可以不使用分布式，但是對于微服務架構來說，分布式幾乎是必會用的技術，由于分布式本身的復雜性，導致微服務架構也變得復雜起來。
接口調整成本高
比如，用戶微服務是要被訂單微服務和電影微服務所調用的，一旦用戶微服務的接口發生大的變動，那么所有依賴它的微服務都要做相應的調整，由于微服務可能非常多，那么調整接口所造成的成本將會明顯提高。
重復造輪子
對于單體架構來講，如果某段業務被多個模塊所共同使用，我們便可以抽象成一個工具類，被所有模塊直接調用，但是微服務卻無法這樣做，因為這個微服務的工具類是不能被其它微服務所直接調用的，從而我們便不得不在每個微服務上都建這么一個工具類，從而導致代碼的重復。
●微服務架構SpringCloud●
服務發現Eureka介紹
Eureka是Netflix開發的服務發現框架，本身是一個基于REST的服務，用于定位服務，以實現云端中間層服務發現和故障轉移。SpringCloud將它集成在其子項目spring-cloud-netflix中，以實現SpringCloud的服務發現功能，類似于Dubbo的注冊中心Zookeeper。實現原理如下：
EureKa采用C-S的設計架構，即包括了EurekaServer（服務端），EureKaclient（客戶端）。
EureKaServer提供服務注冊，各個節點啟動后，在EureKaserver中進行注冊
EureKaClient是一個Java客戶端，用于和服務端進行交互，同時客戶端也是一個內置的默認使用輪詢負載均衡算法的負載均衡器。在應用啟動后，會向EurekaServer發送心跳（默認30秒）。如果EurekaServer在多個心跳周期內沒有接受到某個節點的心跳，EureKaServer將會從服務注冊表中將這個服務移出（默認90秒）。
在項目中業務量不大情況下，例如微服務消費者A可以通過url地址調用微服務生產者B的接口服務，這種直接指定url調用有如下隱患：1、微服務B的IP和端口變了，那微服務A通過之前的url調用微服務B就會報錯；2、因業務量大增，微服務B需要擴容做成集群，如果微服務A還是通過指定url調用微服務B就無法做到集群的負載均衡以及高可用。
綜上所述，我們用Eureka來解決這一難題，各微服務啟動時都注冊服務名在Eureka中，例如微服務消費者A在Eureka中注冊服務名為’consumer,微服務生產者B在Eureka中注冊服務名為’producer’,那微服務消費者A就可以通過指定要調用的服務名’producer’通過Eureka的負載均衡返回實際微服務生產者B的url地址，這樣就解決了以上問題。
微服務之間通信Feign
微服務之間調用接口通過Feign，它是聲明式的Rest客戶端，基于接口的注解方式，它跟Eureka配套使用，Eureka中自帶了Ribbon實現了負載均衡。例如代碼中微服務消費者A通過Feign要調用微服務生產者B的接口服務，只需在微服務A的Feign注解中指定微服務者生產B在Eureka中的注冊服務名即可，如下：
斷路器Hystrix
在微服務架構中，根據業務來拆分成一個個的微服務，微服務與微服務之間可以相互調用，為了保證其高可用，單個微服務通常會集群部署。由于網絡原因或者自身的原因，微服務并不能保證100%可用，如果單個微服務出現問題，調用這個微服務就會出現線程阻塞，此時若有大量的請求涌入該微服務實例，會導致該實例的線程資源會被消耗完畢，導致服務癱瘓。因微服務與微服務之間的依賴性，所以故障會傳播，會對整個微服務系統造成災難性的嚴重后果，這就是微服務故障的“雪崩”效應。
綜上情況，我們使用到了斷路器Hystrix，當對特定的微服務的調用的不可用達到一個閥值（Hystric默認是5秒20次）斷路器將會被打開,下次請求過來微服務會直接通過fallback返回一個固定值快速失敗響應，不會走內部邏輯占用資源。
斷路器還能自動回復，在熔斷機制的異常情況邏輯中，當熔斷器打開的時候，會自動的啟動自動恢復休眠窗（一個計時器，默認10秒），在這個休眠期內，所有請求都會快速失敗。
但是當休眠期到期的時候，此時熔斷器會進入半開狀態，讓下一次請求繼續調用內部資源，而不是快速失敗。如果這時候調用成功，熔斷開關置為關閉狀態。
反之，熔斷開關繼續打開狀態，再次進入快速失敗的狀態，并繼續進行休眠，等待下一次嘗試恢復。斷路器提供了看板監控如下：
服務網關zuul
所有從設備或網站來的請求都會經過Zuul到達后端微服務應用程序。作為一個邊界性質的應用程序，Zuul提供了動態路由、監控、彈性負載和安全功能。Zuul底層利用各種filter實現如下功能：
1、認證和安全：識別每個需要認證的資源，拒絕不符合要求的請求。
2、性能監測：在服務邊界追蹤并統計數據，提供精確的生產視圖。
3、動態路由：根據需要將請求動態路由到后端集群。
4、壓力測試：逐漸增加對集群的流量以了解其性能。
5、負載均衡：預先為每種類型的請求分配容量，當請求超過容量時自動丟棄。
6、靜態資源處理：直接在邊界返回某些響應。
在項目中，一般用到zuul最多的是動態路由、負載均衡，它搭配Eureka使用，當用戶請求過來時，先實現動態路由映射，隱藏真實微服務的IP，在從Eureka拿到實際調用微服務的地址。沒用zuul是以下場景調用微服務，需要直接配置微服務url接口地址：
配置了服務網關zuul后，不管微服務url接口地址是否改變，不影響外部調用：
配置中心SpringCloud Config
我們知道，每個獨立的微服務都有配置文件，一個項目至少有幾個、甚至十幾個微服務以上，如果要修改微服務的配置文件參數，需要登陸到每個微服務項目的resources目錄下進行修改，不方便維護。尤其是更新微服務項目配置后需要重啟，而重啟項目的代價還是很高的。而配置中心SpringCloudConfig提供了公有云遠程Git倉庫、本地Git倉庫，可以把每個微服務的配置文件統一集中管理，當配置文件內容修改時，可以同步到每個微服務的內存中，不需要重啟，實現了高可用，非常方便。
我們可以指定一個微服務為Configserver，實時同步遠程Git倉庫、本地Git倉庫的所有微服務配置文件，當配置文件參數有改動時程序會自動同步到上圖中的微服務A、B中，微服務A、B啟動時也會主動從微服務Configserver同步一次配置文件參數。
以上就是筆者對Spring Cloud在項目中使用原因說明及架構講解，本次入門介紹分享結束，我們下次再見。
文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。
轉載請注明本文地址：http://specialneedsforspecialkids.com/yun/130216.html
摘要：可簡單地認為它是的擴展，負載均衡自然成為不可或缺的特性。是基于開發的服務代理組件，在使用場景中，它與和整合，打造具備服務動態更新和負載均衡能力的服務網關。類似的特性在項目也有體現，它是另一種高性能代理的方案，提供服務發現健康和負載均衡。 摘要： Cloud Native 應用架構隨著云技術的發展受到業界特別重視和關注，尤其是 CNCF（Cloud Native Computing Fo...
摘要：作為面試官，我是如何甄別應聘者的包裝程度語言和等其他語言的對比分析和主從復制的原理詳解和持久化的原理是什么面試中經常被問到的持久化與恢復實現故障恢復自動化詳解哨兵技術查漏補缺最易錯過的技術要點大掃盲意外宕機不難解決，但你真的懂數據恢復嗎每秒 作為面試官，我是如何甄別應聘者的包裝程度Go語言和Java、python等其他語言的對比分析 Redis和MySQL Redis：主從復制的原理詳...
摘要：作為面試官，我是如何甄別應聘者的包裝程度語言和等其他語言的對比分析和主從復制的原理詳解和持久化的原理是什么面試中經常被問到的持久化與恢復實現故障恢復自動化詳解哨兵技術查漏補缺最易錯過的技術要點大掃盲意外宕機不難解決，但你真的懂數據恢復嗎每秒 作為面試官，我是如何甄別應聘者的包裝程度Go語言和Java、python等其他語言的對比分析 Redis和MySQL Redis：主從復制的原理詳...
摘要：目前首個測試版是針對環境的，社區宣稱在未來幾個月內會為虛擬機和等其他環境增加支持。查看下在上的更新時間，截止年月日所有項目均更新于小時內。核心項目最近更新于一個月乃至數月前。所有項目均更新于分鐘內。目前對比來看，則顯得稍遜下來。 showImg(https://segmentfault.com/img/remote/1460000010953149); 在 Kubernetes 容器云...
摘要：可簡單地認為它是的擴展，負載均衡自然成為不可或缺的特性。類似的特性在項目也有體現，它是另一種高性能代理的方案，提供服務發現健康和負載均衡。 Dubbo Cloud Native 實踐與思考 分享簡介 Cloud Native 應用架構隨著云技術的發展受到業界特別重視和關注，尤其是 CNCF（Cloud Native Computing Foundation）項目蓬勃發展之際。Dubbo...
閱讀 1346·2023-01-11 13:20
閱讀 1684·2023-01-11 13:20
閱讀 1132·2023-01-11 13:20
閱讀 1858·2023-01-11 13:20
閱讀 4100·2023-01-11 13:20
閱讀 2704·2023-01-11 13:20
閱讀 1385·2023-01-11 13:20
閱讀 3597·2023-01-11 13:20
