單塊應(yīng)用
單塊應(yīng)用流程
單體應(yīng)用的開發(fā)，會(huì)在intellij idea/eclipse建一個(gè)工程，使用spring mvc+spring+mybatis整合，里面controller、service、dao、mapper、sql代碼，加一大堆的配置文件，還會(huì)根據(jù)需要引入一些redis、elasticsearch、mq之類的依賴。
部署的時(shí)候，使用maven插件，把工程里的所有代碼和依賴打包成一個(gè)jar包/war包，里面包含所有代碼、依賴和配置文件
公司提供給你一臺(tái)linux服務(wù)器，虛擬機(jī)/物理機(jī)，在機(jī)器上你自己先部署了一個(gè)tomcat，然后把你寫好的系統(tǒng)的jar包/war包放到tomcat指定目錄下去，然后重啟一下tomcat，tomcat一旦啟動(dòng)就會(huì)監(jiān)聽類似于8080的端口號(hào)
然后你針對(duì)8080 端口號(hào)發(fā)起http請(qǐng)求，請(qǐng)求會(huì)由tomcat直接轉(zhuǎn)交給你的spring mvc，一層一層調(diào)用你寫的代碼。這就是一個(gè)非常典型的單塊應(yīng)用開發(fā)。
單塊應(yīng)用的問題
- 很多人維護(hù)一個(gè)單塊應(yīng)用，頻繁的進(jìn)行代碼合并，頻繁的解決代碼沖突，解決沖突的時(shí)間和成本很高的，導(dǎo)致開發(fā)效率低下
- 每次上線都要跟最新代碼進(jìn)行合并，重新進(jìn)行全量功能的回歸測(cè)試，很多代碼都可能給有變動(dòng)，必須全量回歸測(cè)試，耗費(fèi)時(shí)間很多，開發(fā)效率低下
- 多人頻繁上線，你等我，我等你，互相協(xié)調(diào)困難，而且可能會(huì)出現(xiàn)別人多次先上線，你多次重復(fù)的合并代碼，解決沖突，全量回歸測(cè)試，做很多次重復(fù)的事情，導(dǎo)致效率低下
- 測(cè)試服務(wù)器都很少，就一臺(tái)測(cè)試服務(wù)器，你開發(fā)好了代碼，你連測(cè)試都不能測(cè)，必須等待別人的分支先測(cè)試完畢上線，你才能去合并代碼，解決沖突，等到一個(gè)測(cè)試環(huán)境可以用，回歸測(cè)試
- 10個(gè)人以內(nèi)維護(hù)一個(gè)單塊應(yīng)用，基本這些成本還不算太大，但是一旦10人以上維護(hù)一個(gè)單塊應(yīng)用，上述的成本會(huì)極大，導(dǎo)致系統(tǒng)每個(gè)需求的測(cè)試和上線，都非常緩慢，要耗費(fèi)大量時(shí)間做全量回歸測(cè)試，上線日期還得互相配合互相等待互相協(xié)調(diào)，一個(gè)疏忽，就可能導(dǎo)致沒側(cè)測(cè)試完全的代碼上線出線上事故
- 如果你想要升級(jí)技術(shù)架構(gòu)，不能隨意升級(jí)，因?yàn)榭赡苡绊憚e人，你得讓所有人都學(xué)習(xí)這個(gè)新技術(shù)架構(gòu)才行；如果你想要升級(jí)已有技術(shù)的版本，不能隨意升級(jí)，因?yàn)榭赡苄掳姹緦?duì)你的代碼沒影響，但是對(duì)別人的代碼有影響
10人以內(nèi)單塊應(yīng)用基本都問題不大，但是一旦10人以上，往往維護(hù)一個(gè)單塊應(yīng)用就比較麻煩了，通常建議的比較合理的是5人以內(nèi)的小團(tuán)隊(duì)負(fù)責(zé)維護(hù)一個(gè)系統(tǒng)，針對(duì)這個(gè)問題，就需要使用微服務(wù)架構(gòu)，把大系統(tǒng)拆分為很多小系統(tǒng)，幾個(gè)人負(fù)責(zé)一個(gè)服務(wù)
這樣每個(gè)服務(wù)獨(dú)立開發(fā)、測(cè)試和上線，代碼沖突少了，每次上線就回歸測(cè)試自己的一個(gè)服務(wù)即可，測(cè)試速度快了；上線是獨(dú)立的，只要向后兼容接口就行了，不需要跟別人等待和協(xié)調(diào)；技術(shù)架構(gòu)和技術(shù)版本的升級(jí)，幾個(gè)人ok就行，成本降低，更加靈活了
微服務(wù)架構(gòu)相關(guān)背景介紹
假設(shè)把一個(gè)多人維護(hù)的單塊應(yīng)用拆分成多個(gè)服務(wù)（A-F），每個(gè)服務(wù)由幾個(gè)人負(fù)責(zé)維護(hù)。
服務(wù)之間會(huì)進(jìn)行通信，互相調(diào)用，但也會(huì)引發(fā)出很多問題，微服務(wù)為了解決這些問題，產(chǎn)生了很多組件，這些組件構(gòu)成了微服務(wù)架構(gòu)。
注冊(cè)中心
如果服務(wù)A想調(diào)用服務(wù)B，就需要知道服務(wù)B的地址，又不能在服務(wù)A中寫死服務(wù)B的地址，所以首先必須有個(gè)注冊(cè)中心。注冊(cè)中心可以讓每一個(gè)服務(wù)都在服務(wù)中心注冊(cè)，上傳自己服務(wù)的地址，其他服務(wù)通過注冊(cè)中心發(fā)現(xiàn)服務(wù)地址。
RPC框架
服務(wù)A和服務(wù)B部署在不同的服務(wù)器上，為了可以調(diào)用遠(yuǎn)程服務(wù)，服務(wù)A需要基于RPC框架去遠(yuǎn)程調(diào)用服務(wù)B
多環(huán)境隔離
多環(huán)境隔離是對(duì)于遠(yuǎn)程調(diào)用來說的，服務(wù)A和服務(wù)B都部署在測(cè)試環(huán)境里，服務(wù)A只能訪問測(cè)試環(huán)境里的服務(wù)B，不能訪問生產(chǎn)環(huán)境里的服務(wù)B。
自動(dòng)化部署
項(xiàng)目的自動(dòng)化部署
分布式事務(wù)
不同于單塊項(xiàng)目，微服務(wù)中每個(gè)服務(wù)都會(huì)有自己的數(shù)據(jù)庫(kù)，一個(gè)用戶請(qǐng)求可能對(duì)多個(gè)數(shù)據(jù)庫(kù)操作，分布式事務(wù)保證事務(wù)的最終一致性。
限流/熔斷/降級(jí)
多個(gè)服務(wù)調(diào)用，如果一個(gè)服務(wù)掛掉，可能引起服務(wù)雪崩，所以需要引入限流/熔斷/降級(jí)機(jī)制。
配置中心
一般來說，單塊系統(tǒng)也會(huì)用到配置中心，在微服務(wù)架構(gòu)中，每個(gè)服務(wù)都有很多配置，如果這些配置每次修改都要修改他的配置文件再重新部署就太坑爹了，所以就需要這么一個(gè)配置中心，修改配置時(shí)直接在配置中心修改，由配置中心推送到服務(wù)上，服務(wù)就可以使用最新的配置了。
監(jiān)控中心
服務(wù)很多，就需要對(duì)每個(gè)服務(wù)進(jìn)行監(jiān)控，還包括整個(gè)系統(tǒng)的業(yè)務(wù)指標(biāo)，每臺(tái)服務(wù)器的內(nèi)存，磁盤，網(wǎng)絡(luò)，I/O，負(fù)載
鏈路監(jiān)控
每個(gè)請(qǐng)求串成了一個(gè)鏈路，需要對(duì)每一條鏈路進(jìn)行監(jiān)控，每個(gè)環(huán)節(jié)是否成功，耗時(shí)
日志中心
在單塊系統(tǒng)中，日志可以直接寫到本地磁盤，在微服務(wù)架構(gòu)中，每個(gè)服務(wù)都寫在自己本地磁盤中，看日志會(huì)非常麻煩，所以需要所有服務(wù)都把日志上傳到日志中心，在日志中心可以進(jìn)行檢索
服務(wù)治理
服務(wù)治理包含上面說的很多東西，包括注冊(cè)，發(fā)現(xiàn)，監(jiān)控，鏈路，日志都可以算是服務(wù)治理的范疇之一，所有關(guān)于服務(wù)管控、管理都可以算是服務(wù)治理。
API網(wǎng)關(guān)
現(xiàn)在架構(gòu)基本上是前后端分離，用戶通過前端/客戶端發(fā)送請(qǐng)求到后端，在前端/客戶端和后端之間，可以增加API網(wǎng)關(guān)，屏蔽掉后端所有服務(wù)地址，避免用戶調(diào)用不同的服務(wù)地址，前端/客戶端直接調(diào)用一個(gè)固定地址，由API網(wǎng)關(guān)根據(jù)請(qǐng)求格式，將不同請(qǐng)求路由給不同地址。便于解耦。
安全認(rèn)證
在API網(wǎng)關(guān)中，還可以進(jìn)行安全認(rèn)證，統(tǒng)一限流等等很多工作。
國(guó)內(nèi)互聯(lián)網(wǎng)大廠的微服務(wù)架構(gòu)演進(jìn)路線
幾乎所有技術(shù)組件都是自研，國(guó)內(nèi)最早的微服務(wù)架構(gòu)幾乎就是一些互聯(lián)網(wǎng)大廠自研了一大堆的組件，來支撐拆分成N多服務(wù)的大型系統(tǒng)的運(yùn)行和多人協(xié)作開發(fā)，包括系統(tǒng)的監(jiān)控和維護(hù)，等等
注冊(cè)中心、RPC框架、多環(huán)境隔離、自動(dòng)化部署、分布式事務(wù)、限流/熔斷/降級(jí)、配置中心、監(jiān)控中心、鏈路監(jiān)控、日志中心、API網(wǎng)關(guān)、安全認(rèn)證、服務(wù)治理
后來在三五年之前，阿里開源的Dubbo比較流行，在國(guó)內(nèi)基本上把系統(tǒng)拆分為微服務(wù)的一些大大小小的公司，RPC框架用的都是阿里開源的Dubbo，注冊(cè)中心用ZooKeeper的居多，當(dāng)時(shí)dubbo+zookeeper基本就是一個(gè)最原始的微服務(wù)技術(shù)架構(gòu)的雛形
至于其他東西，不同的公司可能會(huì)找不同的開源項(xiàng)目，但是都沒太統(tǒng)一的標(biāo)準(zhǔn)，而且很多公司干脆壓根兒就不用其他組件
海外硅谷互聯(lián)網(wǎng)大廠的微服務(wù)架構(gòu)演進(jìn)路線
國(guó)外互聯(lián)網(wǎng)公司，其實(shí)也都是幾個(gè)大公司自己自研，后來逐漸的有一個(gè)叫做netflix公司的微服務(wù)技術(shù)架構(gòu)開源出來，在國(guó)外有很大的影響力，然后接著就被整合到了spring社區(qū)，變成了spring cloud項(xiàng)目，里面整合的是netflix等國(guó)外公司的微服務(wù)相關(guān)組件
早期的spring cloud微服務(wù)體系的組件，是以eureka、feign+ribbon、zuul、hystrix，用zipkin和sleuth做鏈路監(jiān)控，config做配置中心，stream做消息中間件集成，contract做契約測(cè)試支持，當(dāng)然gateway也可以做網(wǎng)關(guān)，consul也是一種注冊(cè)中心，還有跟spring security配合的安全認(rèn)證，跟k8s配合的容器支持
這些都是國(guó)外公司為主的開源項(xiàng)目，spring cloud打包集成在一起，在國(guó)外比較有市場(chǎng)，兩三年前在國(guó)內(nèi)也火了，大量公司都開始擁抱spring cloud，尤其是中小型公司，幾乎都是用spring cloud
因此呈現(xiàn)的一個(gè)狀態(tài)，就是大廠幾乎都是自研，部分大廠是以阿里的dubbo為核心自研的，部分中小型公司還是以dubbo為核心，加上自己找一些開源項(xiàng)目，然后更大比重的中小型公司，就是spring cloud那套技術(shù)架構(gòu)，Spring cloud除了沒有監(jiān)控中心、日志中心、和分布式事務(wù)以外，基本都全的，所以可以快速搭建一套微服務(wù)架構(gòu)。
目前國(guó)內(nèi)公司的主流微服務(wù)技術(shù)棧介紹
兩三年前，因?yàn)榘⒗镩_源的dubbo曾經(jīng)不怎么維護(hù)，然后加上spring cloud完善的技術(shù)棧沖擊進(jìn)來，所以大部分中小型公司都開始擁抱spring cloud，dubbo的使用比例下降很多，所以最近兩三年，國(guó)內(nèi)微服務(wù)這塊，其實(shí)大公司是以純自研/dubbo+自研為主的，中小公司是以全面擁抱spring cloud netflix技術(shù)棧為主的
但是最近一年多，情況產(chǎn)生了變化，因?yàn)榘⒗锏膁ubbo重啟活躍維護(hù)，同時(shí)阿里把自己的微服務(wù)技術(shù)棧融入進(jìn)了spring cloud體系和標(biāo)準(zhǔn)，形成了一個(gè)spring cloud alibaba微服務(wù)技術(shù)組件，也就是以nacos（注冊(cè)中心）、dubbo（RPC框架）、seata（分布式事務(wù)）、sentinal（限流/熔斷/降級(jí)）、rocketmq等技術(shù)為核心的一套技術(shù)體系
注冊(cè)中心：nacos -> eureka
RPC框架：dubbo -> feign+ribbon
分布式事務(wù)：seata -> 無
限流/熔斷/降級(jí)：sentinel -> hystrix
API網(wǎng)關(guān)：無 -> zuul
spring cloud netflix微服務(wù)技術(shù)組件，開始更新的非常不活躍，netflix公司公開宣布他之前開源的一些微服務(wù)組件未來就不會(huì)怎么更新了，這就導(dǎo)致spring cloud netflix微服務(wù)技術(shù)組件的未來有點(diǎn)不太光明，相比之下，spring cloud alibaba微服務(wù)技術(shù)組件，活躍的更新，社區(qū)也重啟，做的很好，宣講，演講，采訪，開始比較活躍起來
所以最近一年其實(shí)很多公司也開始嘗試用spring cloud alibaba的技術(shù)組件，再加上一些其他的開源組件，同時(shí)其他的開源組件里，其實(shí)國(guó)內(nèi)前天互聯(lián)網(wǎng)公司也開源了不少優(yōu)秀的項(xiàng)目，比如說攜程開源的配置中心apollo（spring cloud config），大眾點(diǎn)評(píng)開源的鏈路監(jiān)控CAT（zipkin、slueth），加上其他國(guó)外的優(yōu)秀開源項(xiàng)目，比如Prometheus（監(jiān)控），ELK（日志中心），Spring Cloud Gateway（網(wǎng)關(guān)），等等，可以組成一套全新的以國(guó)內(nèi)開源技術(shù)為核心的微服務(wù)體系
中心公司開始進(jìn)行分化，有部分公司還是spring cloud netflix為主的一套技術(shù)棧，有少部分公司開始嘗試推行spring cloud alibaba技術(shù)棧+國(guó)內(nèi)開源的組件（apollo、CAT）+ Prometheus + ELK + Spring Cloud Gateway（Nginx+lua、Kong、Zuul、API網(wǎng)關(guān)自研）
我個(gè)人傾向于以及比較認(rèn)可的，是這套技術(shù)體系，也認(rèn)為會(huì)是未來國(guó)內(nèi)的主流，因?yàn)閚etflix很多組件維護(hù)的都不夠活躍了，所以衰退是必然的，加上國(guó)內(nèi)的開源項(xiàng)目，都是中文文檔，中文社區(qū)，交流也方便，也很活躍，所以學(xué)習(xí)是以這套國(guó)內(nèi)為主的微服務(wù)技術(shù)體系為主的，也是面向未來的一套技術(shù)體系
