Spring Cloud 在國內(nèi)中小型公司能用起來嗎？從 2016 年初一直到現(xiàn)在，我們?cè)谶@條路上已經(jīng)走了一年多。
在使用 Spring Cloud 之前，我們對(duì)微服務(wù)實(shí)踐是沒有太多的體會(huì)和經(jīng)驗(yàn)的。從最初的開源軟件云收藏來熟悉 Spring Boot，到項(xiàng)目中的慢慢使用，再到最后全面擁抱 Spring Cloud。
這篇文章給大家介紹我們使用 Spring Boot / Cloud 一年多的經(jīng)驗(yàn)總結(jié)。
在開始之前我們先介紹幾個(gè)概念，什么是微服務(wù)，它的特點(diǎn)是什么? Spring Boot / Cloud 都做了那些事情？他們?nèi)咧g又有什么關(guān)系？
在進(jìn)入正文之前，順便給大家推薦一個(gè)Java架構(gòu)方面的交流學(xué)習(xí)群： 725633148 ，里面會(huì)分享一些資深架構(gòu)師錄制的視頻錄像：有Spring，MyBatis，Netty源碼分析，高并發(fā)、高性能、分布式、微服務(wù)架構(gòu)的原理，JVM性能優(yōu)化這些成為架構(gòu)師必備的知識(shí)體系。相信對(duì)于已經(jīng)工作和遇到技術(shù)瓶頸的同學(xué)，在這個(gè)群里會(huì)有你需要的內(nèi)容。有需要的同學(xué)請(qǐng)抓緊時(shí)間加入進(jìn)來。
什么是微服務(wù)
微服務(wù)的概念源于 2014 年 3 月 Martin Fowler 所寫的一篇文章“Microservices”。文中內(nèi)容提到：微服務(wù)架構(gòu)是一種架構(gòu)模式，它提倡將單一應(yīng)用程序劃分成一組小的服務(wù)，服務(wù)之間互相協(xié)調(diào)、互相配合，為用戶提供最終價(jià)值。
每個(gè)服務(wù)運(yùn)行在其獨(dú)立的進(jìn)程中，服務(wù)與服務(wù)間采用輕量級(jí)的通信機(jī)制互相溝通（通常是基于 HTTP 的 RESTful API）。每個(gè)服務(wù)都圍繞著具體業(yè)務(wù)進(jìn)行構(gòu)建，并且能夠被獨(dú)立地部署到生產(chǎn)環(huán)境、類生產(chǎn)環(huán)境等。
另外，應(yīng)盡量避免統(tǒng)一的、集中式的服務(wù)管理機(jī)制，對(duì)具體的一個(gè)服務(wù)而言，應(yīng)根據(jù)業(yè)務(wù)上下文，選擇合適的語言、工具對(duì)其進(jìn)行構(gòu)建。
微服務(wù)是一種架構(gòu)風(fēng)格，一個(gè)大型復(fù)雜軟件應(yīng)用由一個(gè)或多個(gè)微服務(wù)組成。系統(tǒng)中的各個(gè)微服務(wù)可被獨(dú)立部署，各個(gè)微服務(wù)之間是松耦合的。每個(gè)微服務(wù)僅關(guān)注于完成一件任務(wù)并很好地完成該任務(wù)。在所有情況下，每個(gè)任務(wù)代表著一個(gè)小的業(yè)務(wù)能力。
微服務(wù)架構(gòu)優(yōu)勢
01
復(fù)雜度可控
在將應(yīng)用分解的同時(shí)，規(guī)避了原本復(fù)雜度無止境的積累。每一個(gè)微服務(wù)專注于單一功能，并通過定義良好的接口清晰表述服務(wù)邊界。
由于體積小、復(fù)雜度低，每個(gè)微服務(wù)可由一個(gè)小規(guī)模開發(fā)團(tuán)隊(duì)完全掌控，易于保持高可維護(hù)性和開發(fā)效率。
02
獨(dú)立部署
由于微服務(wù)具備獨(dú)立的運(yùn)行進(jìn)程，所以每個(gè)微服務(wù)也可以獨(dú)立部署。當(dāng)某個(gè)微服務(wù)發(fā)生變更時(shí)無需編譯、部署整個(gè)應(yīng)用。
由微服務(wù)組成的應(yīng)用相當(dāng)于具備一系列可并行的發(fā)布流程，使得發(fā)布更加高效，同時(shí)降低對(duì)生產(chǎn)環(huán)境所造成的風(fēng)險(xiǎn)，最終縮短應(yīng)用交付周期。
03
技術(shù)選型靈活
微服務(wù)架構(gòu)下，技術(shù)選型是去中心化的。每個(gè)團(tuán)隊(duì)可以根據(jù)自身服務(wù)的需求和行業(yè)發(fā)展的現(xiàn)狀，自由選擇最適合的技術(shù)棧。
由于每個(gè)微服務(wù)相對(duì)簡單，所以需要對(duì)技術(shù)棧進(jìn)行升級(jí)時(shí)所面臨的風(fēng)險(xiǎn)就較低，甚至完全重構(gòu)一個(gè)微服務(wù)也是可行的。
04
容錯(cuò)
當(dāng)某一組件發(fā)生故障時(shí)，在單一進(jìn)程的傳統(tǒng)架構(gòu)下，故障很有可能在進(jìn)程內(nèi)擴(kuò)散，形成應(yīng)用全局性的不可用。
在微服務(wù)架構(gòu)下，故障會(huì)被隔離在單個(gè)服務(wù)中。若設(shè)計(jì)良好，其他服務(wù)可通過重試、平穩(wěn)退化等機(jī)制實(shí)現(xiàn)應(yīng)用層面的容錯(cuò)。
05
擴(kuò)展
單塊架構(gòu)應(yīng)用也可以實(shí)現(xiàn)橫向擴(kuò)展，就是將整個(gè)應(yīng)用完整的復(fù)制到不同的節(jié)點(diǎn)。當(dāng)應(yīng)用的不同組件在擴(kuò)展需求上存在差異時(shí)，微服務(wù)架構(gòu)便體現(xiàn)出其靈活性，因?yàn)槊總€(gè)服務(wù)可以根據(jù)實(shí)際需求獨(dú)立進(jìn)行擴(kuò)展。
什么是 Spring Boot
Spring Boot 是由 Pivotal 團(tuán)隊(duì)提供的全新框架，其設(shè)計(jì)目的是用來簡化新 Spring 應(yīng)用的初始搭建以及開發(fā)過程。該框架使用了特定的方式來進(jìn)行配置，從而使開發(fā)人員不再需要定義樣板化的配置。
用我的話來理解，就是 Spring Boot 不是什么新的框架，它默認(rèn)配置了很多框架的使用方式，就像 maven 整合了所有的 jar 包，Spring Boot 整合了所有的框架（不知道這樣比喻是否合適）。
Spring Boot 簡化了基于 Spring 的應(yīng)用開發(fā)，通過少量的代碼就能創(chuàng)建一個(gè)獨(dú)立的、產(chǎn)品級(jí)別的 Spring 應(yīng)用。Spring Boot 為 Spring 平臺(tái)及第三方庫提供開箱即用的設(shè)置，這樣你就可以有條不紊地開始。
Spring Boot 的核心思想就是約定大于配置，多數(shù) Spring Boot 應(yīng)用只需要很少的 Spring 配置。采用 Spring Boot 可以大大的簡化你的開發(fā)模式，所有你想集成的常用框架，它都有對(duì)應(yīng)的組件支持。
Spring Cloud 都做了哪些事
Spring Cloud 是一系列框架的有序集合，它利用 Spring Boot 的開發(fā)便利性巧妙地簡化了分布式系統(tǒng)基礎(chǔ)設(shè)施的開發(fā)，如服務(wù)發(fā)現(xiàn)注冊(cè)、配置中心、消息總線、負(fù)載均衡、斷路器、數(shù)據(jù)監(jiān)控等，都可以用 Spring Boot 的開發(fā)風(fēng)格做到一鍵啟動(dòng)和部署。
Spring 并沒有重復(fù)制造輪子，它只是將目前各家公司開發(fā)的比較成熟、經(jīng)得起實(shí)際考驗(yàn)的服務(wù)框架組合起來，通過 Spring Boot 風(fēng)格進(jìn)行再封裝、屏蔽掉了復(fù)雜的配置和實(shí)現(xiàn)原理，最終給開發(fā)者留出了一套簡單易懂、易部署和易維護(hù)的分布式系統(tǒng)開發(fā)工具包。
以下為 Spring Cloud 的核心功能：
分布式/版本化配置。
服務(wù)注冊(cè)和發(fā)現(xiàn)。
路由。
服務(wù)和服務(wù)之間的調(diào)用。
負(fù)載均衡。
斷路器。
分布式消息傳遞。
我們?cè)賮砜匆粡垐D：
解釋一下這張圖中各組件的運(yùn)行流程：
所有請(qǐng)求都統(tǒng)一通過 API 網(wǎng)關(guān)（Zuul）來訪問內(nèi)部服務(wù)。
網(wǎng)關(guān)接收到請(qǐng)求后，從注冊(cè)中心（Eureka）獲取可用服務(wù)。
由 Ribbon 進(jìn)行均衡負(fù)載后，分發(fā)到后端的具體實(shí)例。
微服務(wù)之間通過 Feign 進(jìn)行通信處理業(yè)務(wù)。
Hystrix 負(fù)責(zé)處理服務(wù)超時(shí)熔斷。
Turbine 監(jiān)控服務(wù)間的調(diào)用和熔斷相關(guān)指標(biāo)。
當(dāng)然上面只是 Spring Cloud 體系的一部分，Spring Cloud 共集成了 19 個(gè)子項(xiàng)目，里面都包含一個(gè)或者多個(gè)第三方的組件或者框架！
Spring Cloud 工具框架：
Spring Cloud Config，配置中心，利用 git 集中管理程序的配置。
Spring Cloud Netflix，集成眾多 Netflix 的開源軟件。
Spring Cloud Bus，消息總線，利用分布式消息將服務(wù)和服務(wù)實(shí)例連接在一起，用于在一個(gè)集群中傳播狀態(tài)的變化 。
Spring Cloud for Cloud Foundry，利用 Pivotal Cloudfoundry 集成你的應(yīng)用程序。
Spring Cloud Foundry Service Broker，為建立管理云托管服務(wù)的服務(wù)代理提供了一個(gè)起點(diǎn)。
Spring Cloud Cluster，基于 Zookeeper、Redis、Hazelcast、Consul 實(shí)現(xiàn)的領(lǐng)導(dǎo)選舉和平民狀態(tài)模式的抽象和實(shí)現(xiàn)。
Spring Cloud Consul，基于 Hashicorp Consul 實(shí)現(xiàn)的服務(wù)發(fā)現(xiàn)和配置管理。
Spring Cloud Security，在 Zuul 代理中為 OAuth3 rest 客戶端和認(rèn)證頭轉(zhuǎn)發(fā)提供負(fù)載均衡。
Spring Cloud Sleuth Spring Cloud，應(yīng)用的分布式追蹤系統(tǒng)和 Zipkin、HTrace、ELK 兼容。
Spring Cloud Data Flow，一個(gè)云本地程序和操作模型，組成數(shù)據(jù)微服務(wù)在一個(gè)結(jié)構(gòu)化的平臺(tái)上。
Spring Cloud Stream，基于 Redis、Rabbit、Kafka 實(shí)現(xiàn)的消息微服務(wù)，簡單聲明模型用以在 Spring Cloud 應(yīng)用中收發(fā)消息。
Spring Cloud Stream App Starters，基于 Spring Boot 為外部系統(tǒng)提供 Spring 的集成。
Spring Cloud Task，短生命周期的微服務(wù)，為 Spring Boot 應(yīng)用簡單聲明添加功能和非功能特性。
Spring Cloud Task App Starters。
Spring Cloud Zookeeper，服務(wù)發(fā)現(xiàn)和配置管理基于 Apache Zookeeper。
Spring Cloud for Amazon Web Services，快速和亞馬遜網(wǎng)絡(luò)服務(wù)集成。
Spring Cloud Connectors，便于 PaaS 應(yīng)用在各種平臺(tái)上連接到后端像數(shù)據(jù)庫和消息經(jīng)紀(jì)服務(wù)。
Spring Cloud Starters，項(xiàng)目已經(jīng)終止并且在 Angel.SR2 后的版本和其他項(xiàng)目合并。
Spring Cloud CLI，插件用 Groovy 快速的創(chuàng)建 Spring Cloud 組件應(yīng)用。
這個(gè)數(shù)量還在一直增加...
三者之間的關(guān)系
微服務(wù)是一種架構(gòu)的理念，提出了微服務(wù)的設(shè)計(jì)原則，從理論為具體的技術(shù)落地提供了指導(dǎo)思想。
Spring Boot 是一套快速配置腳手架，可以基于 Spring Boot 快速開發(fā)單個(gè)微服務(wù)。
Spring Cloud 是一個(gè)基于 Spring Boot 實(shí)現(xiàn)的服務(wù)治理工具包；Spring Boot 專注于快速、方便集成的單個(gè)微服務(wù)個(gè)體；Spring Cloud 關(guān)注全局的服務(wù)治理框架。
Spring Boot / Cloud 是微服務(wù)實(shí)踐的最佳落地方案。
Spring Boot / Cloud 微服務(wù)實(shí)踐背景
2015 年初的時(shí)候，因?yàn)楣緲I(yè)務(wù)的大量發(fā)展，我們開始對(duì)原有的業(yè)務(wù)進(jìn)行拆分，新上的業(yè)務(wù)線也全部使用獨(dú)立的項(xiàng)目來開發(fā)，項(xiàng)目和項(xiàng)目之間通過 http 接口進(jìn)行訪問。
2015 年的業(yè)務(wù)發(fā)展非常迅速，項(xiàng)目數(shù)量也就相應(yīng)急劇擴(kuò)大，到了年底的時(shí)候項(xiàng)目達(dá) 60 多個(gè)，當(dāng)項(xiàng)目數(shù)達(dá)到 30 幾個(gè)的時(shí)候，我們就遇到了問題，經(jīng)常某個(gè)項(xiàng)目因?yàn)閿U(kuò)展增加了新的 IP 地址，就需要被動(dòng)的更新好幾個(gè)相關(guān)的項(xiàng)目。
服務(wù)越來越多，服務(wù)之間的調(diào)用關(guān)系也越來越復(fù)雜，有時(shí)候想畫一張圖來表示項(xiàng)目和項(xiàng)目之間的依賴關(guān)系，線條密密麻麻無法看清。下面有一張圖可以表達(dá)我們的心情：
這個(gè)時(shí)候我們就想找一種方案，可以將我們這么多分布式的服務(wù)給管理起來，到網(wǎng)上進(jìn)行了技術(shù)調(diào)研我們發(fā)現(xiàn)有兩款開源軟件比較適合我們，一個(gè)是 Dubbo，另一個(gè)是 Spring Cloud。
剛開始我們是走了一些彎路的，這兩款框架我們都不熟悉，當(dāng)時(shí)國內(nèi)使用 Spring Cloud 進(jìn)行開發(fā)的企業(yè)非常的少，我在網(wǎng)上也幾乎沒找到太多應(yīng)用的案例。但是 Dubbo 在國內(nèi)的使用還是挺普遍的，相關(guān)的資料各方面都比較完善。
因此在公司擴(kuò)展新業(yè)務(wù)線眾籌平臺(tái)的時(shí)候，技術(shù)選型就先定了 Dubbo，因?yàn)橐彩侨碌臉I(yè)務(wù)沒有什么負(fù)擔(dān)，這個(gè)項(xiàng)目我們大概開發(fā)了 6 個(gè)月投產(chǎn)，上線之初也遇到了一些問題，但最終還比較順利。
在新業(yè)務(wù)線選型使用 Dubbo 的同時(shí)，我們也沒有完全放棄 Spring Cloud，我們抽出了一兩名開發(fā)人員學(xué)習(xí) Spring Boot，我也參與其中。
為了驗(yàn)證 Spring Boot 是否可以到達(dá)實(shí)戰(zhàn)的標(biāo)準(zhǔn)，我們?cè)跇I(yè)余的時(shí)間使用 Spring Boot 開發(fā)了一款開源軟件云收藏，經(jīng)過這個(gè)項(xiàng)目的實(shí)戰(zhàn)驗(yàn)證我們對(duì) Spring Boot 就有了信心。
最重要的是大家體會(huì)到使用 Spring Boot 的各種便利之后，就再也不想使用傳統(tǒng)的方式來進(jìn)行開發(fā)了。
但是還有一個(gè)問題，在選擇了 Spring Boot 進(jìn)行新業(yè)務(wù)開發(fā)的同時(shí)，并沒有解決我們上面的那個(gè)問題，服務(wù)與服務(wù)直接調(diào)用仍然比較復(fù)雜和傳統(tǒng)，這時(shí)候我們就開始研究 Spring Cloud。
因?yàn)榇蠹以谇捌趯?duì) Spring Boot 有了足夠的了解，因此學(xué)習(xí) Spring Cloud 就顯得順風(fēng)順?biāo)?。所以在使?Dubbo 半年之后，我們又全面開始擁抱 Spring Cloud。
為什么選擇使用 Spring Cloud 而放棄了 Dubbo
可能大家會(huì)問，為什么選擇了使用 Dubbo 之后，又選擇全面使用 Spring Cloud 呢？其中有如下四個(gè)原因：
01
從兩個(gè)公司的背景來談
Dubbo，是阿里巴巴服務(wù)化治理的核心框架，并被廣泛應(yīng)用于中國各互聯(lián)網(wǎng)公司；Spring Cloud 是大名鼎鼎的 Spring 家族的產(chǎn)品。
阿里巴巴是一個(gè)商業(yè)公司，雖然也開源了很多的頂級(jí)的項(xiàng)目，但從整體戰(zhàn)略上來講，仍然是服務(wù)于自身的業(yè)務(wù)為主。
Spring 專注于企業(yè)級(jí)開源框架的研發(fā)，不論是在中國還是在世界上使用都非常廣泛，開發(fā)出通用、開源、穩(wěn)健的開源框架是他們的主業(yè)。
02
從社區(qū)活躍度這個(gè)角度來對(duì)比
Dubbo 雖然也是一個(gè)非常優(yōu)秀的服務(wù)治理框架，并且在服務(wù)治理、灰度發(fā)布、流量分發(fā)這方面做的比 Spring Cloud 還好，除過當(dāng)當(dāng)網(wǎng)在此基礎(chǔ)上增加了 rest 支持外，已有兩年多的時(shí)間幾乎沒有任何更新了。
在使用過程中出現(xiàn)問題，開發(fā)者提交到 GitHub 的 Issue 也少有回復(fù)。相反 Spring Cloud 自從發(fā)展到現(xiàn)在，仍然在不斷的高速發(fā)展。
從 GitHub 上提交代碼的頻度和發(fā)布版本的時(shí)間間隔就可以看出，現(xiàn)在 Spring Cloud 即將發(fā)布 2.0 版本，到了后期會(huì)更加完善和穩(wěn)定。
03
從整個(gè)大的平臺(tái)架構(gòu)來講
Dubbo 框架只是專注于服務(wù)之間的治理，如果我們需要使用配置中心、分布式跟蹤這些內(nèi)容都需要自己去集成，這樣無形中增加了使用 Dubbo 的難度。
Spring Cloud 幾乎考慮了服務(wù)治理的方方面面，更有 Spring Boot 這個(gè)大將的支持，開發(fā)起來非常的便利和簡單。
04
從技術(shù)發(fā)展的角度來講
Dubbo 剛出來的那會(huì)技術(shù)理念還是非常先進(jìn)，解決了各大互聯(lián)網(wǎng)公司服務(wù)治理的問題，中國的各中小公司也從中受益不少。
經(jīng)過了這么多年的發(fā)展，互聯(lián)網(wǎng)行業(yè)也是涌現(xiàn)了更多先進(jìn)的技術(shù)和理念，Dubbo 一直停滯不前，自然有些掉隊(duì)，有時(shí)候我個(gè)人也會(huì)感到有點(diǎn)可惜，如果 Dubbo 一直沿著當(dāng)初的那個(gè)路線發(fā)展，并且延伸到周邊，今天可能又是另一番景象了。
Spring 推出Spring Boot / Cloud 也是因?yàn)樽陨淼暮芏嘣?。Spring 最初推崇的輕量級(jí)框架，隨著不斷的發(fā)展也越來越龐大，隨著集成項(xiàng)目越來越多，配置文件也越來越混亂，慢慢的背離最初的理念。
隨著這么多年的發(fā)展，微服務(wù)、分布式鏈路跟蹤等更多新的技術(shù)理念的出現(xiàn)，Spring 急需一款框架來改善以前的開發(fā)模式，因此才會(huì)出現(xiàn) Spring Boot / Cloud 項(xiàng)目。
我們現(xiàn)在訪問 Spring 官網(wǎng)，會(huì)發(fā)現(xiàn) Spring Boot 和 Spring Cloud 已經(jīng)放到首頁最重點(diǎn)突出的三個(gè)項(xiàng)目中的前兩個(gè)，可見 Spring 對(duì)這兩個(gè)框架的重視程度。
因此 Dubbo 曾經(jīng)確實(shí)很牛逼，但是 Spring Cloud 是站在近些年技術(shù)發(fā)展之上進(jìn)行的開發(fā)，因此更具技術(shù)代表性。
如何進(jìn)行微服務(wù)架構(gòu)演進(jìn)
當(dāng)我們將所有的新業(yè)務(wù)都使用 Spring Cloud 這套架構(gòu)之后，就會(huì)出現(xiàn)這樣一個(gè)現(xiàn)象：公司的系統(tǒng)被分成了兩部分，一部分是傳統(tǒng)架構(gòu)的項(xiàng)目；另一部分是微服務(wù)架構(gòu)的項(xiàng)目，如何讓這兩套配合起來使用就成為了關(guān)鍵。
這時(shí)候 Spring Cloud 里面的一個(gè)關(guān)鍵組件解決了我們的問題，就是 Zuul。在 Spring Cloud 架構(gòu)體系內(nèi)的所有微服務(wù)都通過 Zuul 來對(duì)外提供統(tǒng)一的訪問入口，所有需要和微服務(wù)架構(gòu)內(nèi)部服務(wù)進(jìn)行通訊的請(qǐng)求都走統(tǒng)一網(wǎng)關(guān)。如下圖：
從上圖可以看出我們對(duì)服務(wù)進(jìn)行了四種分類，不同服務(wù)遷移的優(yōu)先級(jí)不同：
基礎(chǔ)服務(wù)，是一些基礎(chǔ)組件，與具體的業(yè)務(wù)無關(guān)。比如：短信服務(wù)、郵件服務(wù)。這里的服務(wù)最容易摘出來做微服務(wù)，也是我們第一優(yōu)先級(jí)分離出來的服務(wù)。
業(yè)務(wù)服務(wù)，是一些垂直的業(yè)務(wù)系統(tǒng)，只處理單一的業(yè)務(wù)類型，比如：風(fēng)控系統(tǒng)、積分系統(tǒng)、合同系統(tǒng)。
這類服務(wù)職責(zé)比較單一，根據(jù)業(yè)務(wù)情況來選擇是否遷移，比如：如果突然有需求對(duì)積分系統(tǒng)進(jìn)行大優(yōu)化，我們就趁機(jī)將積分系統(tǒng)進(jìn)行改造，是我們的第二優(yōu)先級(jí)分離出來的服務(wù)。
前置服務(wù)，前置服務(wù)一般為服務(wù)的接入或者輸出服務(wù)，比如網(wǎng)站的前端服務(wù)、app 的服務(wù)接口這類，這是我們第三優(yōu)先級(jí)分離出來的服務(wù)。
組合服務(wù)，組合服務(wù)就是涉及到了具體的業(yè)務(wù)，比如買標(biāo)過程，需要調(diào)用很多垂直的業(yè)務(wù)服務(wù)，這類的服務(wù)我們一般放到最后再進(jìn)行微服務(wù)化架構(gòu)來改造，因?yàn)檫@類服務(wù)最為復(fù)雜，除非涉及到大的業(yè)務(wù)邏輯變更，我們是不會(huì)輕易進(jìn)行遷移。
在這四類服務(wù)之外，新上線的業(yè)務(wù)全部使用 Sprng Boot / Cloud 這套技術(shù)棧。
架構(gòu)演化的步驟
架構(gòu)演化的步驟如下：
在確定使用Spring Boot / Cloud 這套技術(shù)棧進(jìn)行微服務(wù)改造之前，請(qǐng)先梳理平臺(tái)的服務(wù)，對(duì)不同的服務(wù)進(jìn)行分類，以確認(rèn)演化的節(jié)奏。
先讓團(tuán)隊(duì)熟悉 Spring Boot 技術(shù)，并且優(yōu)先在基礎(chǔ)服務(wù)上進(jìn)行技術(shù)改造，推動(dòng)改動(dòng)后的項(xiàng)目投產(chǎn)上線。
當(dāng)團(tuán)隊(duì)熟悉 Spring Boot 之后，再推進(jìn)使用 Spring Cloud 對(duì)原有的項(xiàng)目進(jìn)行改造。
在進(jìn)行微服務(wù)改造過程中，優(yōu)先應(yīng)用于新業(yè)務(wù)系統(tǒng)，前期可以只是少量的項(xiàng)目進(jìn)行了微服務(wù)化改造，隨著大家對(duì)技術(shù)的熟悉度增加，可以加快加大微服務(wù)改造的范圍。
傳統(tǒng)項(xiàng)目和微服務(wù)項(xiàng)目共存是一個(gè)很常見的情況，除非公司業(yè)務(wù)有大的變化，不建議直接遷移核心項(xiàng)目。
服務(wù)拆分
服務(wù)拆分的兩個(gè)原則：
橫向拆分。按照不同的業(yè)務(wù)域進(jìn)行拆分，例如訂單、營銷、風(fēng)控、積分資源等，形成獨(dú)立的業(yè)務(wù)領(lǐng)域微服務(wù)集群。
縱向拆分。把一個(gè)業(yè)務(wù)功能里的不同模塊或者組件進(jìn)行拆分。例如把公共組件拆分成獨(dú)立的原子服務(wù)，下沉到底層，形成相對(duì)獨(dú)立的原子服務(wù)層。這樣一縱一橫，就可以實(shí)現(xiàn)業(yè)務(wù)的服務(wù)化拆分。
要做好微服務(wù)的分層：梳理和抽取核心應(yīng)用、公共應(yīng)用，作為獨(dú)立的服務(wù)下沉到核心和公共能力層，逐漸形成穩(wěn)定的服務(wù)中心，使前端應(yīng)用能更快速的響應(yīng)多變的市場需求。
服務(wù)拆分是越小越好嗎？微服務(wù)的大與小是相對(duì)的。比如在初期，我們把交易拆分為一個(gè)微服務(wù)，但是隨著業(yè)務(wù)量的增大，可能一個(gè)交易系統(tǒng)已經(jīng)慢慢變得很大，并且并發(fā)流量也不小。
為了支撐更多的交易量，我會(huì)把交易系統(tǒng)，拆分為訂單服務(wù)、投標(biāo)服務(wù)、轉(zhuǎn)讓服務(wù)等。因此微服務(wù)的拆分力度需與具體業(yè)務(wù)相結(jié)合，總的原則是服務(wù)內(nèi)部高內(nèi)聚，服務(wù)之間低耦合。
微服務(wù) vs 傳統(tǒng)開發(fā)
使用微服務(wù)有一段時(shí)間了，這種開發(fā)模式和傳統(tǒng)的開發(fā)模式對(duì)比，有很大的不同，如下面幾點(diǎn)：
分工不同，以前我們可能是一個(gè)一個(gè)模塊，現(xiàn)在可能是一人一個(gè)系統(tǒng)。
架構(gòu)不同，服務(wù)的拆分是一個(gè)技術(shù)含量很高的問題，拆分是否合理對(duì)以后發(fā)展影響巨大。
部署方式不同，如果還像以前一樣部署估計(jì)累死了，自動(dòng)化運(yùn)維不可不上。
容災(zāi)不同，好的微服務(wù)可以隔離故障避免服務(wù)整體 down 掉，壞的微服務(wù)設(shè)計(jì)仍然可以因?yàn)橐粋€(gè)子服務(wù)出現(xiàn)問題導(dǎo)致連鎖反應(yīng)。
給數(shù)據(jù)庫帶來的挑戰(zhàn)
每個(gè)微服務(wù)都有自己獨(dú)立的數(shù)據(jù)庫，那么后臺(tái)管理的聯(lián)合查詢?cè)趺刺幚?？這是大家普遍遇到的一個(gè)問題。
有如下三種處理方案：
嚴(yán)格按照微服務(wù)的劃分來做，微服務(wù)相互獨(dú)立，各微服務(wù)數(shù)據(jù)庫也獨(dú)立，后臺(tái)需要展示數(shù)據(jù)時(shí)，調(diào)用各微服務(wù)的接口來獲取對(duì)應(yīng)的數(shù)據(jù)，再進(jìn)行數(shù)據(jù)處理后展示出來，這是標(biāo)準(zhǔn)的用法，也是最麻煩的用法。
將業(yè)務(wù)相關(guān)的表放到一個(gè)庫中，將業(yè)務(wù)無關(guān)的表嚴(yán)格按照微服務(wù)模式來拆分，這樣既可以使用微服務(wù)，也避免了數(shù)據(jù)庫各種切換導(dǎo)致后臺(tái)統(tǒng)計(jì)難以實(shí)現(xiàn)，是一個(gè)折中的方案。
數(shù)據(jù)庫嚴(yán)格按照微服務(wù)的要求來切分，以滿足業(yè)務(wù)高并發(fā)，實(shí)時(shí)或者準(zhǔn)實(shí)時(shí)將各微服務(wù)數(shù)據(jù)庫數(shù)據(jù)同步到 NoSQL 數(shù)據(jù)庫中，在同步的過程中進(jìn)行數(shù)據(jù)清洗，用來滿足后臺(tái)業(yè)務(wù)系統(tǒng)的使用，推薦使用 Mongodb、Hbase 等。
三種方案在不同的公司我都使用過，第一種方案適合業(yè)務(wù)較為簡單的小公司；第二種方案，適合想在原有系統(tǒng)之上，慢慢演化為微服務(wù)架構(gòu)的公司；第三種適合大型高并發(fā)的互聯(lián)網(wǎng)公司。
微服務(wù)的經(jīng)驗(yàn)和建議
01
建議盡量不要使用 Jsp，頁面開發(fā)推薦使用 Thymeleaf
Web 項(xiàng)目建議獨(dú)立部署 Tomcat，不要使用內(nèi)嵌的 Tomcat，內(nèi)嵌 Tomcat 部署 Jsp 項(xiàng)目會(huì)偶現(xiàn)龜速訪問的情況。
02
服務(wù)編排是個(gè)好東西，主要的作用是減少項(xiàng)目中的相互依賴
比如現(xiàn)在有項(xiàng)目 a 調(diào)用項(xiàng)目 b，項(xiàng)目 b 調(diào)用項(xiàng)目 c...一直到 h，是一個(gè)調(diào)用鏈，那么項(xiàng)目上線的時(shí)候需要先更新最底層的 h 再更新 g...更新 c 更新 b 最后是更新項(xiàng)目 a。
這只是一個(gè)調(diào)用鏈，在復(fù)雜的業(yè)務(wù)中有非常多的調(diào)用，如果要記住每一個(gè)調(diào)用鏈對(duì)開發(fā)運(yùn)維人員來說就是災(zāi)難。
有一個(gè)好辦法可以盡量的減少項(xiàng)目間的相互依賴，就是服務(wù)編排，一個(gè)核心的業(yè)務(wù)處理項(xiàng)目，負(fù)責(zé)和各個(gè)微服務(wù)打交道。
比如之前是 a 調(diào)用 b，b 掉用 c，c 調(diào)用 d，現(xiàn)在統(tǒng)一在一個(gè)核心項(xiàng)目 W 中來處理，W 服務(wù)使用 a 的時(shí)候去調(diào)用 b，使用 b 的時(shí)候W去調(diào)用 c。
舉個(gè)例子：在第三方支付業(yè)務(wù)中，有一個(gè)核心支付項(xiàng)目是服務(wù)編排，負(fù)責(zé)處理支付的業(yè)務(wù)邏輯，W 項(xiàng)目使用商戶信息的時(shí)候就去調(diào)用“商戶系統(tǒng)”，需要校驗(yàn)設(shè)備的時(shí)候就去調(diào)用“終端系統(tǒng)”，需要風(fēng)控的時(shí)候就調(diào)用“風(fēng)控系統(tǒng)”，各個(gè)項(xiàng)目需要的依賴參數(shù)都由W來做主控。以后項(xiàng)目部署的時(shí)候，只需要最后啟動(dòng)服務(wù)編排項(xiàng)目即可。
03
不要為了追求技術(shù)而追求技術(shù)
需要考慮以下幾方面的因素：
團(tuán)隊(duì)的技術(shù)人員是否已經(jīng)具備相關(guān)技術(shù)基礎(chǔ)。
公司業(yè)務(wù)是否適合進(jìn)行微服務(wù)化改造，并不是所有的平臺(tái)都適合進(jìn)行微服務(wù)化改造，比如：傳統(tǒng)行業(yè)有很多復(fù)雜垂直的業(yè)務(wù)系統(tǒng)。
Spring Cloud 生態(tài)的技術(shù)有很多，并不是每一種技術(shù)方案都需要用上，適合自己的才是最好的。
總結(jié)
Spring Cloud 對(duì)于中小型互聯(lián)網(wǎng)公司來說是一種福音，因?yàn)檫@類公司往往沒有實(shí)力或者沒有足夠的資金投入去開發(fā)自己的分布式系統(tǒng)基礎(chǔ)設(shè)施，使用 Spring Cloud 一站式解決方案能在從容應(yīng)對(duì)業(yè)務(wù)發(fā)展的同時(shí)大大減少開發(fā)成本。
同時(shí)，隨著近幾年微服務(wù)架構(gòu)和 Docker 容器概念的火爆，也會(huì)讓 Spring Cloud 在未來越來越“云”化的軟件開發(fā)風(fēng)格中立有一席之地。
尤其是在目前五花八門的分布式解決方案中提供了標(biāo)準(zhǔn)化的、全站式的技術(shù)方案，意義可能堪比當(dāng)前 Servlet 規(guī)范的誕生，有效推進(jìn)服務(wù)端軟件系統(tǒng)技術(shù)水平的進(jìn)步。
重慶分公司
重慶分公司
