建站
咨詢
售后
建站咨詢
新聞中心
學習目標
- 回顧架構(gòu)的演進。
- 明確springcloud是什么？
- 明確spring、springboot和springcloud之間的關系。
- 了解springcloud的常用組件及其作用。
第1章 架構(gòu)演進
1、單體架構(gòu)
我相信，絕大部分同學都用過SSM框架進行過開發(fā)，當時你們所在項目組肯定是將所有的功能模塊全部放在了同一個框架里面，只是不同的功能建了一個不同的包，然后所有的功能模塊數(shù)據(jù)存儲在一個數(shù)據(jù)庫里面，然后通過一臺Tomcat容器去啟動服務。
我們注重客戶提出的每個要求，我們充分考慮每一個細節(jié)，我們積極的做好成都網(wǎng)站設計、成都網(wǎng)站建設服務，我們努力開拓更好的視野，通過不懈的努力，成都創(chuàng)新互聯(lián)贏得了業(yè)內(nèi)的良好聲譽，這一切，也不斷的激勵著我們更好的服務客戶。 主要業(yè)務：網(wǎng)站建設,網(wǎng)站制作,網(wǎng)站設計,小程序制作,網(wǎng)站開發(fā),技術開發(fā)實力，DIV+CSS，PHP及ASP，ASP.Net，SQL數(shù)據(jù)庫的技術開發(fā)工程師。
這種架構(gòu)在最開始公司業(yè)務量、數(shù)據(jù)量、并發(fā)量小的情況下是沒問題的，甚至對于開發(fā)人員更友好。
但是來了，但是隨著你公司的發(fā)展，業(yè)務量增大，功能需求增多，數(shù)據(jù)量并發(fā)量也增大的時候，單體架構(gòu)就不行了，為什么呢？
- 隨著業(yè)務量增大，單臺Tomcat很容易達到性能瓶頸，一般的服務器上Tomcat的最大并發(fā)量也就在200左右。
- 因為只有一臺服務器，出現(xiàn)問題就直接掛掉了，此時客戶端都訪問不了服務，這個時候就讓我想起了，讀大學的時候選選修課，每次都要等好幾個小時才能選上，體驗極差。
2、集群架構(gòu)
為了解決上面的這些問題，必須要從根源上進行優(yōu)化。此時集群架構(gòu)出現(xiàn)。
集群架構(gòu)的邏輯其實很簡單，它就是把整個系統(tǒng)從一臺服務器上部署變成了多臺服務器部署，只是對整個系統(tǒng)的復制拷貝。然后增加Nginx服務器做負載均衡而已。
但是集群架構(gòu)也存在一些問題：
- 如果系統(tǒng)中的某個很小的功能發(fā)生了版本迭代，那這個時候就需要將所有的系統(tǒng)全部停掉，然后進行更新。而且可能整個系統(tǒng)非常龐大了，開發(fā)這個大系統(tǒng)的部門人員可能也非常多組織架構(gòu)也不好管理。
- 雖然你系統(tǒng)做了集群，但是數(shù)據(jù)庫往往才是制約你系統(tǒng)性能的最大因素，當并發(fā)量大了，數(shù)據(jù)量大了，數(shù)據(jù)庫是處理不過來的。
3、業(yè)務垂直化拆分
針對上面的問題，架構(gòu)再一次需要改進，整個大系統(tǒng)不適用了，就將不同的功能模塊拆分成小系統(tǒng)。
對業(yè)務進行垂直化拆分，簡單來說，就是可以按照系統(tǒng)的業(yè)務功能拆分出多個業(yè)務模塊子系統(tǒng)。每個子系統(tǒng)由不同的業(yè)務團隊負責。
4、服務化改造
隨著對業(yè)務系統(tǒng)進行垂直化改造之后，以業(yè)務功能緯度拆分出來多個子系統(tǒng)，而在各個子系統(tǒng)中，會存在比較多的共享業(yè)務，比如用戶信息查詢，在支付業(yè)務中會涉及到、在首頁中也會涉及到。那么勢必會造成重復開發(fā)產(chǎn)生非常多的冗余代碼。那么這個時候就引入了服務化改造的思想，也就是 SOA把一些通用的、會被多個上層服務調(diào)用的模塊獨立拆分出來，形成一些共享的基礎服務。這些被拆分出來的共享服務相對來說是比較獨立，并且可重用。 比如用戶管理服務，包含用戶注冊、用戶查詢等功能。比如單點登錄服務。
SOA 的核心目標就是通過服務的流程化來實現(xiàn)業(yè)務的靈活性，而這個流程化其實就是由一系列相關聯(lián)的任務組成，這一系列相關聯(lián)的任務可以通過一系列的服務組合來實現(xiàn)具體的業(yè)務功能SOA 面向服務架構(gòu)，從語義上說，它與面向過程、面向?qū)ο蟆⒚嫦蚪M件一樣，是一種軟件組建及開發(fā)的方式。所以在 SOA 中，服務是最核心的抽象手段，業(yè)務被劃分為一些列粗粒度的業(yè)務服務和業(yè)務流程。
SOA 中更強調(diào) ESB 企業(yè)服務總線，企業(yè)服務總線可以使得服務之間的交互是動態(tài)的，以及服務位置是透明的。這樣的好處是服務的調(diào)用者和服務的提供者之間是高度解耦的。從而使得服務有更高的靈活性以及隔離性。
ESB： 是從面相服務架構(gòu)(SOA)發(fā)展過來的，主要是對多個系統(tǒng)中的服務調(diào)用者和服務提供者的解耦。ESB 本身提供了服務暴露、接入、協(xié)議轉(zhuǎn)化、數(shù)據(jù)格式轉(zhuǎn)化、路由等功能。
SOA 主要解決的問題：
- 信息孤島
- 互聯(lián)互通
- 業(yè)務重用
5、微服務架構(gòu)
業(yè)務系統(tǒng)實施服務化改造后，原本共享的業(yè)務被拆分，形成可復用的服務，可以在最大程度上避免共享業(yè)務的重復建設、資源連接瓶頸等問題出現(xiàn)。那么那些被拆分出來的服務，是否也需要以業(yè)務功能為維度來進行拆分，使之能夠獨立進行部署，以降低業(yè)務藕合和提升容錯性呢？
微服務并不是一種新思想的方法。它更像是一種思想的精煉，是一種服務化思想的最佳實踐方向而已，所以我認為微服務其實是在 SOA 思路下，隨著各個企業(yè)對于服務化治理上不斷地完善，以及對軟件的交付鏈路以及基礎設施逐步成熟之下的一種自然的產(chǎn)物。 微服務也是一種面向服務的架構(gòu)模型，只是它更強調(diào)服務的粒度。也就是服務的職責更加單一更加精煉我們也可以把 SOA 看成是微服務的超集。 也就是多個微服務可以組成一個 soa 服務。
6、微服務和 SOA 架構(gòu)的區(qū)別
經(jīng)常會有同學問，微服務和 SOA 架構(gòu)有什么區(qū)別。這個區(qū)別一定要從架構(gòu)的發(fā)展過程來了解。這兩種架構(gòu)模式，其實本質(zhì)上應該是在分布式架構(gòu)這條時間線上，基于服務化思想的不斷完善，以及基礎設施的逐步成熟之下的一種升級。既然存在于時間線的先后，那也就意味著，這兩種架構(gòu)模式所關注的點不一樣。
|
SOA |
MSA(微服務) |
|
遵循“盡可能多地共享”架構(gòu)方法 |
遵循“盡可能少地共享”架構(gòu)方法 |
|
重要性在于業(yè)務功能重用 |
重要性在于“有界上下文”的概念 |
|
他們有共同的治理和標準 |
他們注重人、合作和其他選擇的自由 |
|
使用企業(yè)服務總線（Enterprise Service bus，ESB）進行通信 |
簡單消息傳遞系統(tǒng) |
|
它們支持多種消息協(xié)議 |
使用輕量級協(xié)議，如HTTP/REST等 |
|
具有更多開銷的多線程來處理I/O |
單線程通常使用事件循環(huán)特性來進行非鎖定I/O處理 |
|
最大限度地提高應用程序服務的可重用性 |
重點在于解耦 |
|
傳統(tǒng)的關系數(shù)據(jù)庫更常用 |
現(xiàn)代的關系數(shù)據(jù)庫更常用 |
|
一個系統(tǒng)性的改變需要修改整體 |
一個系統(tǒng)性的改變是創(chuàng)造一個新的服務 |
|
DevOps/Continuous Delivery正在變得流行，但還沒有成為主流 |
人們強烈關注DevOps/Continuous Delivery |
第2章 Spring Cloud
上一章講到了架構(gòu)的演進過程，事實上不管什么架構(gòu)，都是需要通過合適的框架技術進行落地，從最開始的spring框架，到后來的springboot，再到現(xiàn)在的springcloud，那為什么需要springcloud呢？spring為什么不行呢？
要想整體弄明白這些問題，那我們接下來先弄清楚幾個概念，自己在腦海里面形成一套體系：
- spring在開發(fā)過程中有什么問題？
- springboot的出現(xiàn)解決了什么？
- springboot跟springcloud是什么關系
- springcloud是什么？它包含了什么？
1、spring的問題
事實上spring的出現(xiàn)就是為了簡化開發(fā)的，spring的核心概念絕大部分同學都能說出來，無非就是3個，IoC、DI、AOP，下面稍微解釋一下這仨兄弟是干嘛的。
- IoC實際上就是一個容器，它就是用來裝Bean對象的；回到最最基礎的層面，我們java開發(fā)就是在不斷的通過new創(chuàng)建對象，然后拿到對象之后調(diào)用對象里面的方法。OK，那在實際開發(fā)過程中，如果所有的對象都需要手動去創(chuàng)建將是一個非常繁瑣的過程，也許你有1萬個類，然后這1萬個類在各種地方都要創(chuàng)建對象，這個時候假設用到了A類的對象，然后你在B類中new了對象，如果要在C、D、E等等類中要用到這個對象的話，將會很麻煩，這只是一種情況，在開發(fā)中這種類似的現(xiàn)象隨處可見，所以spring為了解決這個過程，設計了一個IoC的功能，你就理解成一個中心容器，用來裝項目中幾乎所有需要用到的Bean對象。
- IoC的概念理解了，那么這個時候你要想，對象創(chuàng)建了，但是對象里面可能會存在別的一些成員屬性，而這些成員屬性又是另外的一些對象，舉個例子就是A對象里面有個成員屬性是B對象，那這個時候你要去進行引用的關聯(lián)，這一步也非常麻煩和繁瑣，怎么辦呢？spring的DI幫你完成了，在A對象new的過程中，spring就會去中心容器找有沒有B對象，有的話就把這個B對象賦值給A對象的屬性。
- AOP的概念其實更好理解，它是基于動態(tài)代理完成的，你們要清晰的指導，代理就是做增強的，什么意思呢？假設有一個對象的業(yè)務功能就是創(chuàng)建訂單，OK，那我不想直接調(diào)用這個對象的創(chuàng)建訂單功能，我想在創(chuàng)建訂單之前和之后干點別的事情，比如說打印日志這個事，這個時候就用到了代理。
OK，spring基于這仨兄弟確實簡化了很多開發(fā)的流程，但是，在最開始的過程中spring在進行IoC注入對象的過程中，它是基于XML方式的，這個邏輯很容易理解，就是你要把什么對象放到容器中去，只需要在XML文件中配置一下就好了。
但是，正因為這個，使得spring變的無比的繁瑣，你想想，一個項目中得用到多少個對象，每個對象都去配置一下，完犢子了。要寫無數(shù)個XML文件了。
spring開始發(fā)力，要優(yōu)化了，引入注解，但是沒用啊，如果你項目要集成別的組件呢？比如redis，比如mybatis。甚至在微服務項目中要引入集成各種組件的話，那更加崩潰。
其實歸根結(jié)底，spring還是沒有解決IoC注入的復雜流程，以及外部化配置的統(tǒng)一管理。
2、springboot
看過springboot源碼的同學都知道，springboot底層其實會走一遍spring的流程。也就是springboot依賴于spring，同時它也在spring的基礎之上作了一些工作。
具體作了啥，實際上就是解決IoC自動注入和配置統(tǒng)一管理，使得這個工作不再需要程序員去做了，框架自己干了。具體怎么解決的參照之前的內(nèi)容。
3、springcloud生態(tài)
先明確springcloud是什么？網(wǎng)上都說，啊呀springcloud就是做微服務的，它是一個生態(tài)啊等等。進說一些我們聽不懂的。
那我這里用最簡單的語言去解釋一下：
springcloud就是springboot集成各種各樣starter組件的一個集體，springcloud底層核心框架就是springboot，然后springboot集成不同組件的時候不需要程序員去寫XML文件以及配置文件了，而是一些好事之徒，他們基于springboot自動裝配原理寫了starter組件，然后將這些starter組件和springboot的整體我們給了一個名字叫做springcloud。
明白了吧，那知道springcloud是什么之后，在來看這個生態(tài)里面包含了啥，springboot我知道了，starter組件有哪些呢？
這個不用去背，我們自己根據(jù)數(shù)據(jù)流向從整體上去串一串就好了，當你串明白了，那你離架構(gòu)師就不是太遠了。
（1）網(wǎng)關
Gateway組件
我們知道 spring cloud 可以用來開發(fā)微服務，但是應該很少有同學真正知道 spring cloud 是什么。
官方的解釋是：spring cloud 提供了一些可以讓開發(fā)者快速構(gòu)建分布式應用的工具，這些服務可以很好的工作在任何分布式環(huán)境下。
既然提供的是一些快速構(gòu)建微服務應用的工具，那么我們需要了解微服務開發(fā)過程中需要解決哪些問題？
在微服務實施之后，各個服務的拆分粒度很小，對于客戶端來說，做一個操作可能會涉及到后端的多個服務組件的調(diào)用，那意味著它需要頻繁的發(fā)起多次訪問才能進行數(shù)據(jù)聚合實現(xiàn)用戶的功能。
如果我們在所有的微服務之前增加一個網(wǎng)關，對于客戶端來說它需要做什么功能操作直接調(diào)用網(wǎng)關并且告訴網(wǎng)關所要做的事情即可，網(wǎng)關根據(jù)請求的功能對后端的多個服務的數(shù)據(jù)進行聚合聚合哦從而減少客戶端的調(diào)用頻次。
并且，由于有了網(wǎng)關的聚合，我們還可以在網(wǎng)關層對請求進行統(tǒng)一鑒權(quán)和認證； 包括還可以實現(xiàn)限流、請求日志統(tǒng)一記錄、 灰度發(fā)布等等。
（2）遠程通信
Openfeign、Dubbo
服務拆分以后就會涉及到服務的遠程通信，比如 http 協(xié)議或者 rpc 協(xié)議。
（3）服務發(fā)現(xiàn)
Eureka、Nacos
在滿足基礎通信的基礎上，如何做到服務的統(tǒng)一管理以及服務的動態(tài)感知，就需要涉及到服務的注冊中心來實現(xiàn)服務注冊和發(fā)現(xiàn)的功能。
（4）負載均衡
Ribbon、Dubbo
假設服務提供者為了擴大吞吐量，采用 10 臺機器的集群部署，這個時候客戶端從注冊中心獲得服務以后，應該調(diào)用哪臺機器呢？
所以必然有一種負載均衡的機制，來實現(xiàn)客戶端請求的分發(fā)。
（5）熔斷、限流、降級
Hystrix、Sentinel
在分布式架構(gòu)中，各個服務節(jié)點一定需要滿足高可用，所以對于服務本身來說，一方面是在有準備的前提下做好充足的擴容。另一方面，服務需要有熔斷、限流、降級的能力。
當一個服務調(diào)用另外一個服務，可能因為網(wǎng)絡原因、或者連接池滿等問題導致頻繁出現(xiàn)錯誤，需要有一種熔斷機制，來防止因為請求堆積導致整個應用雪崩。
當發(fā)現(xiàn)整個系統(tǒng)的確負載過高的時候，可以選擇降級某些功能或某些調(diào)用，保證最重要的交易流程的通過，以及最重要的資源全部用于保證最核心的流程。
在設置了熔斷以及降級策略后，還有一種手段來保護系統(tǒng)，就是限流算法。
我們能夠通過全鏈路壓測了解到整個系統(tǒng)的吞吐量，但實際上的流量可能會超過我們預期的值，比如存在惡意攻擊、或者突然的高峰流量。在這種情況下可以通過限流來保護系統(tǒng)不崩潰，但是對于部分用戶來說，會出現(xiàn)被限流導致體驗不好的情況。
（6）配置中心
Config、Nacos
服務拆分以后，服務的數(shù)量非常多，如果所有的配置都以配置文件的方式放在應用本地的話，非常難以管理，可以想象當有幾百上千個進程中有一個配置出現(xiàn)了問題，是很難將它找出來的，因而需要有統(tǒng)一的配置中心，來管理所有的配置，進行統(tǒng)一的配置下發(fā)。
在微服務中，配置往往分為幾類，一類是幾乎不變的配置，這種配置可以直接打在容器鏡像里面，第二類是啟動時就會確定的配置，這種配置往往通過環(huán)境變量，在容器啟動的時候傳進去，第三類就是統(tǒng)一的配置，需要通過配置中心進行下發(fā)，例如在大促的情況下，有些功能需要降級，哪些功能可以降級，哪些功能不能降級，都可以在配置文件中統(tǒng)一配置。
（7）分布式事務
Seata
對于數(shù)據(jù)庫的垂直拆分，已經(jīng)服務的拆分，單體的數(shù)據(jù)庫事務完全不能滿足需求了，這個時候就需要一個第三方的協(xié)調(diào)工具來做到統(tǒng)一管理事務提交回滾等操作，這個時候Seata出現(xiàn)了。
4、服務帶來的問題
（1）業(yè)務團隊的痛點
- 對于業(yè)務開發(fā)團隊而言，最強的是技術嗎？一定不是，業(yè)務團隊最強的一定是對于業(yè)務的理解和熟悉程度。
- 而業(yè)務應用的核心價值，就是為了實現(xiàn)業(yè)務場景，而不是寫微服務，微服務只是一種實現(xiàn)業(yè)務的手段。
- 業(yè)務團隊除了關心業(yè)務之外，他們所面臨的最大的挑戰(zhàn)在于，如何保證系統(tǒng)的穩(wěn)定性何可擴展性、如何設計一個安全的 open api。如果對服務進行拆分、如何保證跨庫的數(shù)據(jù)一致性。以及對于舊系統(tǒng)的改造。
- 于公司層面而言，業(yè)務團隊的壓力還來自于時間人力的投入，我們用于被各種 deadline 趕著走。所以作為一個業(yè)務程序員，如果在這個 deadline 之前還需要花更多的時間投入在spring cloud 這些工具的學習上，那無疑是雪上加霜。公司對于業(yè)務團隊的考核，永遠只看結(jié)果！
（2）跨語言帶來的問題
微服務有一個很重要的特性，就是不同的微服務可以采用自己最擅長的語言來編寫程序。這種特性在企業(yè)中落地的時候又會帶來一些問題。
比如公司內(nèi)部會開發(fā)一些公共的類庫或者框架，也或者會使用第三方的類庫或者框架來實現(xiàn)某些功能。
但是由于公司的微服務用了各種各樣的語言，那意味著這些類庫需要針對不同的語言開發(fā)兼容版本。如果是主流語言還好，如果是一些小眾語言，那對于這些基礎組件的開發(fā)者而言無疑是晴天霹靂.
（3）總結(jié)
從這些痛點中可以發(fā)現(xiàn)，我們所做的所有非業(yè)務類的事情，都是為了保證把請求發(fā)送到正確的地方，并且能夠及時或得正確的結(jié)果。那對于對于業(yè)務開發(fā)人員而言，是否有必要去關心這些呢？
回到最開始我們說的一個例子，在進行計算機網(wǎng)絡通信的時候，開發(fā)人員有必要去關心網(wǎng)絡通信的細節(jié)嗎？ 我們在使用 http 協(xié)議進行數(shù)據(jù)傳輸時，關心過底層是使用 TCP 還是 udp？數(shù)據(jù)是怎么傳輸?shù)模?/p>
既然我們不需要關心這些，那對于微服務架構(gòu)中的這些問題，業(yè)務開發(fā)人員為什么一定要關心服務的通訊呢？
新聞名稱：架構(gòu)演變之SpringCloud由來
分享鏈接：http://www.5511xx.com/article/codssgp.html
