【51CTO.com原創(chuàng)稿件】Spring Cloud 在國(guó)內(nèi)中小型公司能用起來(lái)嗎?從 2016 年初一直到現(xiàn)在，我們?cè)谶@條路上已經(jīng)走了一年多。

在使用 Spring Cloud 之前，我們對(duì)微服務(wù)實(shí)踐是沒有太多的體會(huì)和經(jīng)驗(yàn)的。從最初的開源軟件云收藏來(lái)熟悉 Spring Boot，到項(xiàng)目中的慢慢使用，再到***全面擁抱 Spring Cloud。

[[206862]]

這篇文章給大家介紹我們使用 Spring Boot / Cloud 一年多的經(jīng)驗(yàn)總結(jié)。

在開始之前我們先介紹幾個(gè)概念，什么是微服務(wù)，它的特點(diǎn)是什么? Spring Boot / Cloud 都做了那些事情?他們?nèi)咧g又有什么關(guā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ù)上下文，選擇合適的語(yǔ)言、工具對(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)勢(shì)

01復(fù)雜度可控

在將應(yīng)用分解的同時(shí)，規(guī)避了原本復(fù)雜度無(wú)止境的積累。每一個(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í)無(wú)需編譯、部署整個(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ì)簡(jiǎn)單，所以需要對(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ì)目的是用來(lái)簡(jiǎn)化新 Spring 應(yīng)用的初始搭建以及開發(fā)過程。該框架使用了特定的方式來(lái)進(jìn)行配置，從而使開發(fā)人員不再需要定義樣板化的配置。

用我的話來(lái)理解，就是 Spring Boot 不是什么新的框架，它默認(rèn)配置了很多框架的使用方式，就像 maven 整合了所有的 jar 包，Spring Boot 整合了所有的框架(不知道這樣比喻是否合適)。

Spring Boot 簡(jiǎn)化了基于 Spring 的應(yīng)用開發(fā)，通過少量的代碼就能創(chuàng)建一個(gè)獨(dú)立的、產(chǎn)品級(jí)別的 Spring 應(yīng)用。Spring Boot 為 Spring 平臺(tái)及第三方庫(kù)提供開箱即用的設(shè)置，這樣你就可以有條不紊地開始。

Spring Boot 的核心思想就是約定大于配置，多數(shù) Spring Boot 應(yīng)用只需要很少的 Spring 配置。采用 Spring Boot 可以大大的簡(jiǎn)化你的開發(fā)模式，所有你想集成的常用框架，它都有對(duì)應(yīng)的組件支持。

Spring Cloud 都做了哪些事

Spring Cloud 是一系列框架的有序集合，它利用 Spring Boot 的開發(fā)便利性巧妙地簡(jiǎn)化了分布式系統(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ù)框架組合起來(lái)，通過 Spring Boot 風(fēng)格進(jìn)行再封裝、屏蔽掉了復(fù)雜的配置和實(shí)現(xiàn)原理，最終給開發(fā)者留出了一套簡(jiǎn)單易懂、易部署和易維護(hù)的分布式系統(tǒng)開發(fā)工具包。

以下為 Spring Cloud 的核心功能：

• 分布式/版本化配置。
• 服務(wù)注冊(cè)和發(fā)現(xiàn)。
• 路由。
• 服務(wù)和服務(wù)之間的調(diào)用。
• 負(fù)載均衡。
• 斷路器。
• 分布式消息傳遞。

我們?cè)賮?lái)看一張圖：

解釋一下這張圖中各組件的運(yùn)行流程：

• 所有請(qǐng)求都統(tǒng)一通過 API 網(wǎng)關(guān)(Zuul)來(lái)訪問內(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 代理中為 OAuth2 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ù)，簡(jiǎn)單聲明模型用以在 Spring Cloud 應(yīng)用中收發(fā)消息。
• Spring Cloud Stream App Starters，基于 Spring Boot 為外部系統(tǒng)提供 Spring 的集成。
• Spring Cloud Task，短生命周期的微服務(wù)，為 Spring Boot 應(yīng)用簡(jiǎn)單聲明添加功能和非功能特性。
• 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ù)庫(kù)和消息經(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)目來(lái)開發(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ù)越來(lái)越多，服務(wù)之間的調(diào)用關(guān)系也越來(lái)越復(fù)雜，有時(shí)候想畫一張圖來(lái)表示項(xiàng)目和項(xiàng)目之間的依賴關(guān)系，線條密密麻麻無(wú)法看清。下面有一張圖可以表達(dá)我們的心情：

[[206863]]

這個(gè)時(shí)候我們就想找一種方案，可以將我們這么多分布式的服務(wù)給管理起來(lái)，到網(wǎng)上進(jìn)行了技術(shù)調(diào)研我們發(fā)現(xiàn)有兩款開源軟件比較適合我們，一個(gè)是 Dubbo，另一個(gè)是 Spring Cloud。

剛開始我們是走了一些彎路的，這兩款框架我們都不熟悉，當(dāng)時(shí)國(guó)內(nèi)使用 Spring Cloud 進(jìn)行開發(fā)的企業(yè)非常的少，我在網(wǎng)上也幾乎沒找到太多應(yīng)用的案例。但是 Dubbo 在國(guó)內(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)的方式來(lái)進(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è)公司的背景來(lái)談

Dubbo，是阿里巴巴服務(wù)化治理的核心框架，并被廣泛應(yīng)用于中國(guó)各互聯(lián)網(wǎng)公司;Spring Cloud 是大名鼎鼎的 Spring 家族的產(chǎn)品。

阿里巴巴是一個(gè)商業(yè)公司，雖然也開源了很多的***的項(xiàng)目，但從整體戰(zhàn)略上來(lái)講，仍然是服務(wù)于自身的業(yè)務(wù)為主。

Spring 專注于企業(yè)級(jí)開源框架的研發(fā)，不論是在中國(guó)還是在世界上使用都非常廣泛，開發(fā)出通用、開源、穩(wěn)健的開源框架是他們的主業(yè)。

02從社區(qū)活躍度這個(gè)角度來(lái)對(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)來(lái)講

Dubbo 框架只是專注于服務(wù)之間的治理，如果我們需要使用配置中心、分布式跟蹤這些內(nèi)容都需要自己去集成，這樣無(wú)形中增加了使用 Dubbo 的難度。

Spring Cloud 幾乎考慮了服務(wù)治理的方方面面，更有 Spring Boot 這個(gè)大將的支持，開發(fā)起來(lái)非常的便利和簡(jiǎn)單。

04從技術(shù)發(fā)展的角度來(lái)講

Dubbo 剛出來(lái)的那會(huì)技術(shù)理念還是非常先進(jìn)，解決了各大互聯(lián)網(wǎng)公司服務(wù)治理的問題，中國(guó)的各中小公司也從中受益不少。

經(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)樽陨淼暮芏嘣颉pring 最初推崇的輕量級(jí)框架，隨著不斷的發(fā)展也越來(lái)越龐大，隨著集成項(xiàng)目越來(lái)越多，配置文件也越來(lái)越混亂，慢慢的背離最初的理念。

隨著這么多年的發(fā)展，微服務(wù)、分布式鏈路跟蹤等更多新的技術(shù)理念的出現(xiàn)，Spring 急需一款框架來(lái)改善以前的開發(fā)模式，因此才會(huì)出現(xiàn) Spring Boot / Cloud 項(xiàng)目。

我們現(xiàn)在訪問 Spring 官網(wǎng)，會(huì)發(fā)現(xiàn) Spring Boot 和 Spring Cloud 已經(jīng)放到首頁(yè)最重點(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)目，如何讓這兩套配合起來(lái)使用就成為了關(guān)鍵。

這時(shí)候 Spring Cloud 里面的一個(gè)關(guān)鍵組件解決了我們的問題，就是 Zuul。在 Spring Cloud 架構(gòu)體系內(nèi)的所有微服務(wù)都通過 Zuul 來(lái)對(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ù)無(wú)關(guān)。比如：短信服務(wù)、郵件服務(wù)。這里的服務(wù)最容易摘出來(lái)做微服務(wù)，也是我們***優(yōu)先級(jí)分離出來(lái)的服務(wù)。
• 業(yè)務(wù)服務(wù)，是一些垂直的業(yè)務(wù)系統(tǒng)，只處理單一的業(yè)務(wù)類型，比如：風(fēng)控系統(tǒng)、積分系統(tǒng)、合同系統(tǒng)。
• 這類服務(wù)職責(zé)比較單一，根據(jù)業(yè)務(wù)情況來(lái)選擇是否遷移，比如：如果突然有需求對(duì)積分系統(tǒng)進(jìn)行大優(yōu)化，我們就趁機(jī)將積分系統(tǒng)進(jìn)行改造，是我們的第二優(yōu)先級(jí)分離出來(lái)的服務(wù)。
• 前置服務(wù)，前置服務(wù)一般為服務(wù)的接入或者輸出服務(wù)，比如網(wǎng)站的前端服務(wù)、app 的服務(wù)接口這類，這是我們第三優(yōu)先級(jí)分離出來(lái)的服務(wù)。

組合服務(wù)，組合服務(wù)就是涉及到了具體的業(yè)務(wù)，比如買標(biāo)過程，需要調(diào)用很多垂直的業(yè)務(wù)服務(wù)，這類的服務(wù)我們一般放到***再進(jìn)行微服務(wù)化架構(gòu)來(lái)改造，因?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)行拆分，例如訂單、營(yíng)銷、風(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)多變的市場(chǎ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ù)庫(kù)帶來(lái)的挑戰(zhàn)

每個(gè)微服務(wù)都有自己獨(dú)立的數(shù)據(jù)庫(kù)，那么后臺(tái)管理的聯(lián)合查詢?cè)趺刺幚?這是大家普遍遇到的一個(gè)問題。

有如下三種處理方案：

• 嚴(yán)格按照微服務(wù)的劃分來(lái)做，微服務(wù)相互獨(dú)立，各微服務(wù)數(shù)據(jù)庫(kù)也獨(dú)立，后臺(tái)需要展示數(shù)據(jù)時(shí)，調(diào)用各微服務(wù)的接口來(lái)獲取對(duì)應(yīng)的數(shù)據(jù)，再進(jìn)行數(shù)據(jù)處理后展示出來(lái)，這是標(biāo)準(zhǔn)的用法，也是最麻煩的用法。
• 將業(yè)務(wù)相關(guān)的表放到一個(gè)庫(kù)中，將業(yè)務(wù)無(wú)關(guān)的表嚴(yán)格按照微服務(wù)模式來(lái)拆分，這樣既可以使用微服務(wù)，也避免了數(shù)據(jù)庫(kù)各種切換導(dǎo)致后臺(tái)統(tǒng)計(jì)難以實(shí)現(xiàn)，是一個(gè)折中的方案。
• 數(shù)據(jù)庫(kù)嚴(yán)格按照微服務(wù)的要求來(lái)切分，以滿足業(yè)務(wù)高并發(fā)，實(shí)時(shí)或者準(zhǔn)實(shí)時(shí)將各微服務(wù)數(shù)據(jù)庫(kù)數(shù)據(jù)同步到 NoSQL 數(shù)據(jù)庫(kù)中，在同步的過程中進(jìn)行數(shù)據(jù)清洗，用來(lái)滿足后臺(tái)業(yè)務(wù)系統(tǒng)的使用，推薦使用 Mongodb、Hbase 等。

三種方案在不同的公司我都使用過，***種方案適合業(yè)務(wù)較為簡(jiǎn)單的小公司;第二種方案，適合想在原有系統(tǒng)之上，慢慢演化為微服務(wù)架構(gòu)的公司;第三種適合大型高并發(fā)的互聯(lián)網(wǎng)公司。

微服務(wù)的經(jīng)驗(yàn)和建議

01建議盡量不要使用 Jsp，頁(yè)面開發(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)維人員來(lái)說就是災(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 中來(lái)處理，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來(lái)做主控。以后項(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)公司來(lái)說是一種福音，因?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 在未來(lái)越來(lái)越“云”化的軟件開發(fā)風(fēng)格中立有一席之地。

尤其是在目前五花八門的分布式解決方案中提供了標(biāo)準(zhǔn)化的、全站式的技術(shù)方案，意義可能堪比當(dāng)前 Servlet 規(guī)范的誕生，有效推進(jìn)服務(wù)端軟件系統(tǒng)技術(shù)水平的進(jìn)步。

[[206864]]

張強(qiáng)

第三方支付公司資深架構(gòu)師

 

 

網(wǎng)名純潔的微笑，曾經(jīng)先后在互聯(lián)網(wǎng)金融、第三方支付公司擔(dān)任高級(jí) Java 工程師、架構(gòu)師、技術(shù)經(jīng)理、技術(shù)負(fù)責(zé)人等職務(wù)。在互聯(lián)網(wǎng)金融領(lǐng)域工作期間，從零參與公司技術(shù)平臺(tái)建設(shè)，組織平臺(tái)進(jìn)行過四次大架構(gòu)升級(jí)，目前在一家第三方支付公司做架構(gòu)師，負(fù)責(zé)支付公司大數(shù)據(jù)平臺(tái)建設(shè)。

【51CTO原創(chuàng)稿件，合作站點(diǎn)轉(zhuǎn)載請(qǐng)注明原文作者和出處為51CTO.com】