4.1.1.微服務架構的現狀及未來【上】
時長：54min
內容概述：
1.什么是微服務
2.微服務與soa
3.springcloud是什么
4.springCloud生態
5.service Mesh
1.1.什么是微服務
1.1.1.架構演進過程
1.1.1.1.單體架構
早期，任何一個網站，都是從單體架構發展而來的。因為早期，不會有龐大的用戶量，及數據體量。也不會有較為復雜的業務結構。
當然，現在，很多創業型公司，可能都是直接使用springCloud進行微服務設計。
所謂單體架構，就是整個項目，打一個war包布署到一台tomcat服務器上。當然，數據庫會單獨安裝在一台服務器上。
開發可以使用ssm,或ssh框架。開發人員【可以使用兩人組，一前端，一后端】
隨着產品上線。可能會遇到很多的問題，如：用戶量增加，服務器的性能是否能跟上？系統業務復雜度增加以后，后端系統架構業務的耦合性是否越來越強?
數據量增加以后，數據庫是否能夠支撐數據的查詢，和數據導入。。。
如下圖所示：
因此，使用考慮服務器集群布署來進行優化。
1.1.1.2.集群布署
何謂集群布署？
當用戶大量增加，必然就會出現同一時刻，多個用戶同時訪問一個接口。即同一時刻，發送大量請求。
而服務器的作用，就是接收用戶請求，處理數據，並返回數據。當請求大量增加以后，就相當於一個人要干活變多了，處理速度就慢了。那怎么辦呢？
只好找一個同伴來幫忙，因此，增加一台服務器【甚至是多台服務器】
然后，多台服務器進行分工，一起來處理這些用戶請求。
那么，大家的工作壓力都減輕了，干活的效率就提高了。
集群布署，是一種水平伸縮方式。能夠提升服務端處理性能，提升並發性能。
除了提升並發處理性能之外，還可以保證高可用性【一台服務器掛掉后，可以用另一台頂上】。
但是，隨着用戶的大量增加，不同的用戶需求不同，產品功能就會增加更多。產品業務邏輯就會越加復雜。
如果所有業務都放在一個容器，必然會帶來一個問題，系統的耦合性越來越大。業務的體量也會變大。
耦合性增加，帶來的問題是，當進行一個需求變更修改代碼時，就會導致相關代碼也需要大量修改。
給開發工作帶來很大工作量和難度。
因此，需要進行業務解耦。即根據業務進行拆分系統。
1.1.1.3.垂直化架構【集群】
所謂垂直架構，就是根據業務進行系統拆分，不同的業務布署在不同服務器上。
舉例來說，對於一個電商系統，常涉及到訂單系統，用戶系統，商品系統。
打開淘寶的網站，我們會發現，針對不同的業務系統，會對應一個子域名。
同樣，針對不同業務，會布署不同的數據庫，以達到業務隔離的效果。
垂直架構，主要作用是降低業務耦合度。
由於業務拆分，不同的業務，對應獨立的數據庫，帶來的問題是，當不同系統之間存在服務調用時，就可能出現很多冗余代碼。
如：用戶要查詢用戶的訂單信息，用戶系統就需要查詢訂單庫。這種跨系統調用，就會導致很多重復代碼。
當底層數據庫服務發生變化時，上層依賴它的服務就需要相應修改。如：只是修改了訂單庫的底層服務，但是用戶系統和訂單系統，及其它依賴訂單庫的系統都需要修改。
所以，這里還是存在緊密的耦合性。基於這個問題，引入了服務化【SOA】的概念。
1.1.1.4.服務化【soa】
所謂服務化架構，也稱面向服務編程。
它是用於解決系統的共享業務問題。即解決不同系統間代碼冗余問題，解決方案是在各業務系統與數據庫服務之間，引入中間服務層。
服務層，以一種特定的規范來處理。這里會提供的服務接口，這些接口需要滿足某種協議，如：rpc協議。
引入中間服務層之后，也就有了共享服務。然后不同系統就可以以遠程通信的方式，調用共享服務。
服務化，主要解決業務重用，和數據互聯互通。
Soa到微服務，會發生什么變化呢？
實際上變化並不大，微服務是基於soa,更為細粒化服務的演進。它的核心，是降低業務的耦合性。
1.1.1.5.微服務化
所謂微服務，是在服務化的基礎下，對服務更為細粒度的拆分。
如：用戶服務，拆分為用戶基本服務，用戶帳戶服務，用戶積分服務。。。
進行微服務化之后，系統被拆分成很多個的子系統，並且獨立布署。
對服務器布署，在原來虛擬化技術的基礎下，提出容器化布署。
1.soa與微服務的區別
1.微服務，是對soa一種思想升華，和技術提煉。
2.微服務的主要目的是解耦，而soa的主要目的是服務重用。
3.微服務關注服務粒度，soa關注服務復用。
4.微服務會使用輕量級的通信協議，如：restful,可以很好支持跨語言，會使得服務生態更加完善。
5.微服務，由於服務的大量拆分，更加依賴於服務運維技術。如：docker+k8s容器化技術。
2.微服務架構下的業務需求
微服務架構下存在哪些需求呢？如下圖示：
舉例說明：
比如，用戶服務，調用訂單服務，查詢數據。這是一種跨系統，跨服務器通信，也就是一種遠程通信。
遠程通信有很多協議，如：rpc通信，涉及中間件，如：restful,dubbo,jsf【京東】，hsf【阿里】，螞蟻金服【Sofa】
這里簡要說明下遠程通信基礎。
下面引出第一個需求，eureka-server注冊中心，服務注冊中心是什么呢？
【1】服務注冊中心
以用戶服務，調用訂單服務為例。說明遠程通信與服務注冊中心的關聯。
服務調用過程，必然涉及rpc遠程通信，而服務必然會做集群【防止單點故障，達到高可用】，即會涉及到多個服務。
假設訂單服務，布署3個節點【相當於3台服務器】，一旦涉及到多台服務器，必須需要用到負載均衡器，來分發請求。
需要一個前提是，服務調用者，需要知道服務提供者在什么地方【提供者的地址】
因此，需要對地址進行維護，可以考慮在配置文件中寫死，http://ip:port/url...,但是，如果服務提供者的地址發生變化，就
需要修改配置。這種方式明顯是有缺陷的，主要問題有：
》無法做到服務動態感知。
所謂動態感知，比如說，訂單服務布署3個節點，其中一個節點掛掉之后，服務調用者不知道提供者的節點，是否有掛掉。
在不知道的情況下，服務調用者【消費者】，每次請求發過去，都會失敗。
》配置文件中硬編碼式配置，維護困難。
因為微服務中會有大量的服務，每個服務會涉及到多個節點，針對這些服務，把服務地址寫在配置文件中，會有很大的工作量，不利於維護。
所以，需要思考一種高效管理服務地址的方案。因此，才引入服務注冊中心。
服務注冊中心，需要滿足基礎的兩點：服務動態感知，服務地址高效管理。
有了服務注冊中心，就可以把服務注冊，到注冊中心。服務注冊中心，相當於電話通訊錄【聯系人名單】，服務就相當於聯系人，根據名稱就很輕松地找到
具體的聯系人【具體服務】。
服務消費者，如何拿到服務呢?直接從注冊中心獲取。
注冊中心的實現組件，包括Nacos,consul,eureka,zookeeper,redis
注意：微服務與分布式架構
微服務是屬於分布式架構，微服務強調服務架構的一個特征，分布式是整個架構的一個特點，是架構層面的概念。
【2】負載均衡器
配置在客戶端，組件，如：ribbon，涉及到負載均衡算法---輪詢，隨機，平均數。。。
4.1.2.微服務架構的現狀及未來【下】
時長：1h10min
【3】配置中心
為什么要有一個配置中心呢？主要是為了放置一些公共的配置文件。
如：數據庫連接，內部常量配置，開關配置，線程池大小。
單獨布署一個配置中心，能夠很方便地找到配置數據，也可以直接對配置進行修改。
如果在項目中進行配置，修改配置文件，需要進行重新布署，此外，安全性也是個問題。
再有，如果服務布署10個節點，需要對10個節點的配置進行修改，就需要對10個節點，重新布署。
造成運維困難。因此，引入配置中心組件。
有了配置中心以后，在服務啟動之前，會先從配置中心加載配置數據，緩存到本地。一般配置中心，會有
一個統一的維護入口，如：Dashboard,配置人員可以在客戶端訪問這個配置頁面。當然，配置中心，一般會對
訪問人員進行權限校驗，如果具備相關權限，就可以對配置數據進行crud.
當配置中心配置數據，有更新后，會主動推送，告訴相關的服務，這個配置變化了。然后應用就可以基於新的
配置進行處理，從而實現動態地配置管理，而不需要重啟服務。
動態配置數據，如：閥值配置，開關配置，第三方服務【密鑰，key...】
配置中心開源組件，apollo【攜程】/Nacos/disconf/zookeeper/diamend/spring cloud config
【4】網關
客戶端，一個請求發起之后，會先經過網關，然后由網關進行路由。
為什么需要網關呢？
服務調用涉及到一個安全性問題，服務調用中，針對每一個節點，會進行一個授權判斷。怎么知道請求用戶是
誰？
此外，服務每次調用，可能需要做監控，限流處理。當然可以放到服務層去處理，但是，最好是對這些處理進行抽離，放
到網關層，做統一授權，日志記錄，權限認證，限流，熔斷處理。
網關，簡單來說，就是請求路由。網關要實現這些功能，就需要對請求進行過濾，攔截。
同樣，為了滿足高可用，網關也需要進行集群，布署多個節點，所以， 網關之前也需要nginx做反向代理。
網關，實現開源組件，spring cloud gateway/spring cloud zuul
整個系統，進行分布式設計，微服務拆分，大大降低系統耦合度，提高了性能。但是，還是存在問題:
>可用性【不可能100%可用】
》性能不能所有的用戶需求
后端系統服務吞吐量是可以測試出來的，通過壓測，鏈路跟蹤，系統監控。
壓測，一般是針對核心服務。整個系統來說，它的吞吐量是有限的，當用戶量非常大的情況下，如何保證系統不會垮掉？
通常會做一些處理：
限流：為了保護系統不被大量請求沖擊垮掉。限流算法【令牌桶，滑動窗口，漏桶，guava ratelimiter】，sentinel【阿里】,hystrix【spring】
通常是對流量閥值進行判斷。hystrix可以針對方法，服務做降級，做熔斷。
熔斷：
降級：保證核心服務可用。
分為主動降級，被動降級。
緩存：
【5】負載均衡器
開源組件，keepalived/Nginx/openRestry/Kong/Orange/tyk
【6】spring Cloud Bus異步化總線通信
系統涉及到異步化通信時，可以基於spring Cloud Bus通信。引入第三方通信組件，如：Kafka/RocketMQ.
【7】鏈路監控
整個系統，還有一個很重要的部分，就是系統監控。
傳統的方式，是通過日志監控。如：當出現一個bug時，通常是登錄到服務器，查看日志，然后定位問題。
然而，在微服務架構下，一個系統存在非常多的節點，一個請求可能經過多個節點。如：我需要定位一個請求，
從發起請求，到返回結果整個過程，耗時10秒，怎么去定位這個耗時，主要是發生在什么地方？
spring cloud提供一個鏈路監控，sleuth + zipkin.監控原理是：
每一個請求進來以后，會生成一個tranceId【整個鏈路唯一】,spanId【每一個節點中每一個請求中是唯一的】
鏈路監控，開源組件有：sleuth +zipkin/pinpoint/skywalking/cat/jaeger.
系統監控，還可以通過dashboard大盤展示，讓運維人員和開發人員查看。
1.2.spring Cloud生態
springCloud是什么？
在微服務架構下，存在很多問題。針對這些問題，和相應場景，都需要提供一定的解決方案。
在沒有spring Cloud之前，spring生態可以整合市場上的一些開源組件，來提供解決方案。需要開發人員自己進行整合，整合過程會存在，版本兼容和其他一些問題。
Spring很會體諒我們開發人員，它為我們提供了一套整合方案，這就是spring cloud生態。它提供了快速構建微服務的多種技術組件。
服務注冊：eureka
1.2.1.spring Cloud版本命名
為什么要這么為版本命名呢？
使用A,B。。。H,這種大版本命名。因為spring cloud生態下各種組件依賴版本各不相同。而在大版本下會有各種組件的小版本整合。
spring cloud版本，與springboot版本有很大的關聯性。