上次寫了一篇文章叫Spring Cloud在國內(nèi)中小型公司能用起來嗎?介紹了Spring Cloud是否能在中小公司使用起來嗤军，這篇文章是它的姊妹篇茸歧。其實(shí)我們在這條路上已經(jīng)走了一年多口四，從16年初到現(xiàn)在拜效。在使用Spring Cloud之前我們對微服務(wù)實(shí)踐是沒有太多的體會和經(jīng)驗的创南。從最初的開源軟件云收藏來熟悉Spring Boot巷屿，到項目中的慢慢使用赃梧，再到最后全面擁抱Spring Cloud滤蝠。這篇文章就給大家介紹一下我們使用Spring Boot/Cloud一年多的經(jīng)驗。
在開始之前我們先介紹一下幾個概念授嘀，什么是微服務(wù)物咳，它的特點(diǎn)是什么? Spring Boot/Cloud都做了那些事情？他們?nèi)咧g又有什么聯(lián)系蹄皱？
技術(shù)背景
什么是微服務(wù)
微服務(wù)的概念源于2014年3月Martin Fowler所寫的一篇文章“Microservices”览闰。
微服務(wù)架構(gòu)是一種架構(gòu)模式，它提倡將單一應(yīng)用程序劃分成一組小的服務(wù)巷折，服務(wù)之間互相協(xié)調(diào)压鉴、互相配合，為用戶提供最終價值锻拘。每個服務(wù)運(yùn)行在其獨(dú)立的進(jìn)程中油吭，服務(wù)與服務(wù)間采用輕量級的通信機(jī)制互相溝通（通常是基于HTTP的RESTful API）。每個服務(wù)都圍繞著具體業(yè)務(wù)進(jìn)行構(gòu)建，并且能夠被獨(dú)立地部署到生產(chǎn)環(huán)境上鞠、類生產(chǎn)環(huán)境等际邻。另外，應(yīng)盡量避免統(tǒng)一的芍阎、集中式的服務(wù)管理機(jī)制世曾，對具體的一個服務(wù)而言，應(yīng)根據(jù)業(yè)務(wù)上下文谴咸，選擇合適的語言轮听、工具對其進(jìn)行構(gòu)建。
微服務(wù)是一種架構(gòu)風(fēng)格岭佳，一個大型復(fù)雜軟件應(yīng)用由一個或多個微服務(wù)組成血巍。系統(tǒng)中的各個微服務(wù)可被獨(dú)立部署，各個微服務(wù)之間是松耦合的珊随。每個微服務(wù)僅關(guān)注于完成一件任務(wù)并很好地完成該任務(wù)述寡。在所有情況下，每個任務(wù)代表著一個小的業(yè)務(wù)能力叶洞。
微服務(wù)架構(gòu)優(yōu)勢
復(fù)雜度可控：在將應(yīng)用分解的同時鲫凶，規(guī)避了原本復(fù)雜度無止境的積累。每一個微服務(wù)專注于單一功能衩辟，并通過定義良好的接口清晰表述服務(wù)邊界螟炫。由于體積小、復(fù)雜度低艺晴，每個微服務(wù)可由一個小規(guī)模開發(fā)團(tuán)隊完全掌控昼钻，易于保持高可維護(hù)性和開發(fā)效率。
獨(dú)立部署：由于微服務(wù)具備獨(dú)立的運(yùn)行進(jìn)程封寞，所以每個微服務(wù)也可以獨(dú)立部署然评。當(dāng)某個微服務(wù)發(fā)生變更時無需編譯、部署整個應(yīng)用狈究。由微服務(wù)組成的應(yīng)用相當(dāng)于具備一系列可并行的發(fā)布流程沾瓦，使得發(fā)布更加高效，同時降低對生產(chǎn)環(huán)境所造成的風(fēng)險谦炒，最終縮短應(yīng)用交付周期。
技術(shù)選型靈活：微服務(wù)架構(gòu)下风喇，技術(shù)選型是去中心化的宁改。每個團(tuán)隊可以根據(jù)自身服務(wù)的需求和行業(yè)發(fā)展的現(xiàn)狀，自由選擇最適合的技術(shù)棧魂莫。由于每個微服務(wù)相對簡單还蹲，故需要對技術(shù)棧進(jìn)行升級時所面臨的風(fēng)險就較低，甚至完全重構(gòu)一個微服務(wù)也是可行的。
容錯：當(dāng)某一組建發(fā)生故障時谜喊，在單一進(jìn)程的傳統(tǒng)架構(gòu)下潭兽，故障很有可能在進(jìn)程內(nèi)擴(kuò)散，形成應(yīng)用全局性的不可用斗遏。在微服務(wù)架構(gòu)下山卦，故障會被隔離在單個服務(wù)中。若設(shè)計良好诵次，其他服務(wù)可通過重試账蓉、平穩(wěn)退化等機(jī)制實(shí)現(xiàn)應(yīng)用層面的容錯。
擴(kuò)展：單塊架構(gòu)應(yīng)用也可以實(shí)現(xiàn)橫向擴(kuò)展逾一，就是將整個應(yīng)用完整的復(fù)制到不同的節(jié)點(diǎn)铸本。當(dāng)應(yīng)用的不同組件在擴(kuò)展需求上存在差異時，微服務(wù)架構(gòu)便體現(xiàn)出其靈活性遵堵，因為每個服務(wù)可以根據(jù)實(shí)際需求獨(dú)立進(jìn)行擴(kuò)展箱玷。
什么是Spring Boot
Spring Boot是由Pivotal團(tuán)隊提供的全新框架，其設(shè)計目的是用來簡化新Spring應(yīng)用的初始搭建以及開發(fā)過程陌宿。該框架使用了特定的方式來進(jìn)行配置锡足，從而使開發(fā)人員不再需要定義樣板化的配置。用我的話來理解限番，就是Spring Boot其實(shí)不是什么新的框架舱污，它默認(rèn)配置了很多框架的使用方式，就像maven整合了所有的jar包弥虐，Spring Boot整合了所有的框架（不知道這樣比喻是否合適）扩灯。
Spring Boot簡化了基于Spring的應(yīng)用開發(fā)，通過少量的代碼就能創(chuàng)建一個獨(dú)立的霜瘪、產(chǎn)品級別的Spring應(yīng)用珠插。 Spring Boot為Spring平臺及第三方庫提供開箱即用的設(shè)置，這樣你就可以有條不紊地開始颖对。Spring Boot的核心思想就是約定大于配置捻撑，多數(shù)Spring Boot應(yīng)用只需要很少的Spring配置。采用Spring Boot可以大大的簡化你的開發(fā)模式缤底，所有你想集成的常用框架顾患，它都有對應(yīng)的組件支持。
Spring Cloud都做了哪些事
Spring Cloud是一系列框架的有序集合个唧。它利用Spring Boot的開發(fā)便利性巧妙地簡化了分布式系統(tǒng)基礎(chǔ)設(shè)施的開發(fā)江解，如服務(wù)發(fā)現(xiàn)注冊、配置中心徙歼、消息總線犁河、負(fù)載均衡鳖枕、斷路器、數(shù)據(jù)監(jiān)控等桨螺，都可以用Spring Boot的開發(fā)風(fēng)格做到一鍵啟動和部署宾符。Spring并沒有重復(fù)制造輪子，它只是將目前各家公司開發(fā)的比較成熟灭翔、經(jīng)得起實(shí)際考驗的服務(wù)框架組合起來魏烫，通過Spring Boot風(fēng)格進(jìn)行再封裝屏蔽掉了復(fù)雜的配置和實(shí)現(xiàn)原理，最終給開發(fā)者留出了一套簡單易懂缠局、易部署和易維護(hù)的分布式系統(tǒng)開發(fā)工具包
以下為Spring Cloud的核心功能：
分布式/版本化配置
服務(wù)注冊和發(fā)現(xiàn)
路由
服務(wù)和服務(wù)之間的調(diào)用
負(fù)載均衡
斷路器
分布式消息傳遞
我們再來看一張圖：
通過這張圖则奥，我們來了解一下各組件配置使用運(yùn)行流程：
1、請求統(tǒng)一通過API網(wǎng)關(guān)（Zuul）來訪問內(nèi)部服務(wù).
2狭园、網(wǎng)關(guān)接收到請求后读处，從注冊中心（Eureka）獲取可用服務(wù)
3、由Ribbon進(jìn)行均衡負(fù)載后唱矛，分發(fā)到后端具體實(shí)例
4罚舱、微服務(wù)之間通過Feign進(jìn)行通信處理業(yè)務(wù)
5、Hystrix負(fù)責(zé)處理服務(wù)超時熔斷
6绎谦、Turbine監(jiān)控服務(wù)間的調(diào)用和熔斷相關(guān)指標(biāo)
Spring Cloud體系介紹
上圖只是Spring Cloud體系的一部分管闷，Spring Cloud共集成了19個子項目，里面都包含一個或者多個第三方的組件或者框架窃肠！
Spring Cloud 工具框架
1包个、Spring Cloud Config 配置中心，利用git集中管理程序的配置冤留。
2碧囊、Spring Cloud Netflix 集成眾多Netflix的開源軟件
3、Spring Cloud Bus 消息總線纤怒，利用分布式消息將服務(wù)和服務(wù)實(shí)例連接在一起糯而，用于在一個集群中傳播狀態(tài)的變化
4、Spring Cloud for Cloud Foundry 利用Pivotal Cloudfoundry集成你的應(yīng)用程序
5泊窘、Spring Cloud Cloud Foundry Service Broker 為建立管理云托管服務(wù)的服務(wù)代理提供了一個起點(diǎn)熄驼。
6、Spring Cloud Cluster 基于Zookeeper, Redis, Hazelcast, Consul實(shí)現(xiàn)的領(lǐng)導(dǎo)選舉和平民狀態(tài)模式的抽象和實(shí)現(xiàn)烘豹。
7瓜贾、Spring Cloud Consul 基于Hashicorp Consul實(shí)現(xiàn)的服務(wù)發(fā)現(xiàn)和配置管理。
8携悯、Spring Cloud Security 在Zuul代理中為OAuth2 rest客戶端和認(rèn)證頭轉(zhuǎn)發(fā)提供負(fù)載均衡
9阐虚、Spring Cloud Sleuth SpringCloud應(yīng)用的分布式追蹤系統(tǒng)，和Zipkin蚌卤，HTrace实束，ELK兼容。
10逊彭、Spring Cloud Data Flow 一個云本地程序和操作模型咸灿，組成數(shù)據(jù)微服務(wù)在一個結(jié)構(gòu)化的平臺上。
11侮叮、Spring Cloud Stream 基于Redis,Rabbit,Kafka實(shí)現(xiàn)的消息微服務(wù)避矢，簡單聲明模型用以在Spring Cloud應(yīng)用中收發(fā)消息。
12囊榜、Spring Cloud Stream App Starters 基于Spring Boot為外部系統(tǒng)提供spring的集成
13审胸、Spring Cloud Task 短生命周期的微服務(wù)，為SpringBooot應(yīng)用簡單聲明添加功能和非功能特性卸勺。
14砂沛、Spring Cloud Task App Starters
15、Spring Cloud Zookeeper 服務(wù)發(fā)現(xiàn)和配置管理基于Apache Zookeeper曙求。
16碍庵、Spring Cloud for Amazon Web Services 快速和亞馬遜網(wǎng)絡(luò)服務(wù)集成。
17悟狱、Spring Cloud Connectors 便于PaaS應(yīng)用在各種平臺上連接到后端像數(shù)據(jù)庫和消息經(jīng)紀(jì)服務(wù)静浴。
18、Spring Cloud Starters （項目已經(jīng)終止并且在Angel.SR2后的版本和其他項目合并）
19挤渐、Spring Cloud CLI 插件用Groovy快速的創(chuàng)建Spring Cloud組件應(yīng)用苹享。
當(dāng)然這個數(shù)量還在一直增加...
三者之間的關(guān)系
微服務(wù)是一種架構(gòu)的理念，提出了微服務(wù)的設(shè)計原則浴麻，從理論為具體的技術(shù)落地提供了指導(dǎo)思想得问。Spring Boot是一套快速配置腳手架，可以基于Spring Boot快速開發(fā)單個微服務(wù)白胀；Spring Cloud是一個基于Spring Boot實(shí)現(xiàn)的服務(wù)治理工具包椭赋；Spring Boot專注于快速峰髓、方便集成的單個微服務(wù)個體良蛮，Spring Cloud關(guān)注全局的服務(wù)治理框架。
Spring Boot/Cloud是微服務(wù)實(shí)踐的最佳落地方案该编。
實(shí)戰(zhàn)經(jīng)歷
遇到問題向抢，尋找方案
2015年初的時候认境，因為公司業(yè)務(wù)的大量發(fā)展，我們開始對原有的業(yè)務(wù)進(jìn)行拆分挟鸠，新上的業(yè)務(wù)線也全部使用獨(dú)立的項目來開發(fā)叉信，項目和項目之間通過http接口進(jìn)行訪問。15年的業(yè)務(wù)發(fā)展非常迅速艘希，項目數(shù)量也就相應(yīng)急劇擴(kuò)大硼身，到了15底的時候項目達(dá)60多個硅急，當(dāng)項目數(shù)達(dá)到30幾個的時候，其實(shí)我們就遇到了問題佳遂，經(jīng)常某個項目因為擴(kuò)展增加了新的IP地址营袜，我們就需要被動的更新好幾個相關(guān)的項目。服務(wù)越來越多丑罪，服務(wù)之間的調(diào)用關(guān)系也越來越復(fù)雜荚板，有時候想畫一張圖來表示項目和項目之間的依賴關(guān)系，線條密密麻麻無法看清吩屹。網(wǎng)上有一張圖可以表達(dá)我們的心情跪另。
這個時候我們就想找一種方案，可以將我們這么多分布式的服務(wù)給管理起來煤搜，到網(wǎng)上進(jìn)行了技術(shù)調(diào)研免绿。我們發(fā)現(xiàn)有兩款開源軟件比較適合我們，一個是Dubbo宅楞，一個是Spring Cloud针姿。
其實(shí)剛開始我們是走了一些彎路的。這兩款框架我們當(dāng)時都不熟悉厌衙，當(dāng)時國內(nèi)使用Spring Cloud進(jìn)行開發(fā)的企業(yè)非常的少距淫，我在網(wǎng)上也幾乎沒找到太多應(yīng)用的案例。但是Dubbo當(dāng)時在國內(nèi)的使用還是挺普遍的婶希，相關(guān)的資料各方面都比較完善榕暇。因此在公司擴(kuò)展新業(yè)務(wù)線眾籌平臺的時候，技術(shù)選型就先定了Dubbo喻杈，因為也是全新的業(yè)務(wù)沒有什么負(fù)擔(dān)彤枢，這個項目我們大概開發(fā)了六個月投產(chǎn)，上線之初也遇到了一些問題筒饰，但最終還比較順利缴啡。
在新業(yè)務(wù)線選型使用Dubbo的同時，我們也沒有完全放棄Spring Cloud瓷们，我們抽出了一兩名開發(fā)人員學(xué)習(xí)Spring Boot我也參與其中业栅，為了驗證Spring Boot是否可以到達(dá)實(shí)戰(zhàn)的標(biāo)準(zhǔn)，我們在業(yè)余的時間使用Spring Boot開發(fā)了一款開源軟件云收藏谬晕，經(jīng)過這個項目的實(shí)戰(zhàn)驗證我們對Spring Boot就有了信心碘裕。最重要的是大家體會到使用Spring Boot的各種便利之后，就再也不想使用傳統(tǒng)的方式來進(jìn)行開發(fā)了攒钳。
但是還有一個問題帮孔，在選擇了Spring Boot進(jìn)行新業(yè)務(wù)開發(fā)的同時，并沒有解決我們上面的那個問題不撑，服務(wù)于服務(wù)直接調(diào)用仍然比較復(fù)雜和傳統(tǒng)文兢，這時候我們就開始研究Spring Cloud晤斩。因為大家在前期對Spring Boot有了足夠的了解，因此學(xué)習(xí)Sprig Cloud就顯得順風(fēng)順?biāo)四芳帷Ｋ栽谑褂肈ubbo半年之后尸昧，我們又全面開始擁抱Spring Cloud。
為什么選擇使用Spring Cloud而放棄了Dubbo
可能大家會問旷偿，為什么選擇了使用Dubbo之后，而又選擇全面使用Spring Cloud呢爆侣？其中有幾個原因：
1）從兩個公司的背景來談：Dubbo萍程，是阿里巴巴服務(wù)化治理的核心框架，并被廣泛應(yīng)用于中國各互聯(lián)網(wǎng)公司兔仰；Spring Cloud是大名鼎鼎的Spring家族的產(chǎn)品茫负。阿里巴巴是一個商業(yè)公司，雖然也開源了很多的頂級的項目乎赴，但從整體戰(zhàn)略上來講忍法，仍然是服務(wù)于自身的業(yè)務(wù)為主。Spring專注于企業(yè)級開源框架的研發(fā)榕吼，不論是在中國還是在世界上使用都非常廣泛饿序，開發(fā)出通用、開源羹蚣、穩(wěn)健的開源框架就是他們的主業(yè)原探。
2）從社區(qū)活躍度這個角度來對比，Dubbo雖然也是一個非常優(yōu)秀的服務(wù)治理框架顽素，并且在服務(wù)治理咽弦、灰度發(fā)布、流量分發(fā)這方面做的比Spring Cloud還好胁出，除過當(dāng)當(dāng)網(wǎng)在基礎(chǔ)上增加了rest支持外型型，已有兩年多的時間幾乎都沒有任何更新了。在使用過程中出現(xiàn)問題全蝶，提交到github的Issue也少有回復(fù)闹蒜。
相反Spring Cloud自從發(fā)展到現(xiàn)在，仍然在不斷的高速發(fā)展裸诽，從github上提交代碼的頻度和發(fā)布版本的時間間隔就可以看出嫂用，現(xiàn)在Spring Cloud即將發(fā)布2.0版本，到了后期會更加完善和穩(wěn)定丈冬。
- 從整個大的平臺架構(gòu)來講嘱函，dubbo框架只是專注于服務(wù)之間的治理，如果我們需要使用配置中心埂蕊、分布式跟蹤這些內(nèi)容都需要自己去集成往弓，這樣無形中使用dubbo的難度就會增加疏唾。Spring Cloud幾乎考慮了服務(wù)治理的方方面面，更有Spring Boot這個大將的支持函似，開發(fā)起來非常的便利和簡單槐脏。
4）從技術(shù)發(fā)展的角度來講，Dubbo剛出來的那會技術(shù)理念還是非常先進(jìn)撇寞，解決了各大互聯(lián)網(wǎng)公司服務(wù)治理的問題顿天，中國的各中小公司也從中受益不少。經(jīng)過了這么多年的發(fā)展蔑担，互聯(lián)網(wǎng)行業(yè)也是涌現(xiàn)了更多先進(jìn)的技術(shù)和理念牌废，Dubbo一直停滯不前，自然有些掉隊啤握，有時候我個人也會感到有點(diǎn)可惜鸟缕，如果Dubbo一直沿著當(dāng)初的那個路線發(fā)展，并且延伸到周邊排抬，今天可能又是另一番景象了懂从。
Spring 推出Spring Boot/Cloud也是因為自身的很多原因。Spring最初推崇的輕量級框架蹲蒲，隨著不斷的發(fā)展也越來越龐大番甩，隨著集成項目越來越多，配置文件也越來越混亂悠鞍，慢慢的背離最初的理念对室。隨著這么多年的發(fā)展，微服務(wù)咖祭、分布式鏈路跟蹤等更多新的技術(shù)理念的出現(xiàn)掩宜，Spring急需一款框架來改善以前的開發(fā)模式，因此才會出現(xiàn)Spring Boot/Cloud項目么翰，我們現(xiàn)在訪問Spring官網(wǎng)牺汤，會發(fā)現(xiàn)Spring Boot和Spring Cloud已經(jīng)放到首頁最重點(diǎn)突出的三個項目中的前兩個，可見Spring對這兩個框架的重視程度浩嫌。
總結(jié)一下檐迟，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)之后，就會出現(xiàn)這樣一個現(xiàn)象骚腥，公司的系統(tǒng)被分成了兩部分敦间，一部分是傳統(tǒng)架構(gòu)的項目，一部分是微服務(wù)架構(gòu)的項目，如何讓這兩套配合起來使用就成為了關(guān)鍵廓块，這時候Spring Cloud里面的一個關(guān)鍵組件解決了我們的問題厢绝，就是Zuul。在Spring Cloud架構(gòu)體系內(nèi)的所有微服務(wù)都通過Zuul來對外提供統(tǒng)一的訪問入口带猴，所有需要和微服務(wù)架構(gòu)內(nèi)部服務(wù)進(jìn)行通訊的請求都走統(tǒng)一網(wǎng)關(guān)昔汉。如下圖：
從上圖可以看出我們對服務(wù)進(jìn)行了分類，有四種：基礎(chǔ)服務(wù)拴清、業(yè)務(wù)服務(wù)靶病、組合服務(wù)、前置服務(wù)口予。不同服務(wù)遷移的優(yōu)先級不同
基礎(chǔ)服務(wù)嫡秕，是一些基礎(chǔ)組件，與具體的業(yè)務(wù)無關(guān)苹威。比如：短信服務(wù)、郵件服務(wù)驾凶。這里的服務(wù)最容易摘出來做微服務(wù)牙甫，也是我們第一優(yōu)先級分離出來的服務(wù)。
業(yè)務(wù)服務(wù)调违，是一些垂直的業(yè)務(wù)系統(tǒng)窟哺，只處理單一的業(yè)務(wù)類型，比如：風(fēng)控系統(tǒng)技肩、積分系統(tǒng)且轨、合同系統(tǒng)。這類服務(wù)職責(zé)比較單一虚婿，根據(jù)業(yè)務(wù)情況來選擇是否遷移旋奢，比如：如果突然有需求對積分系統(tǒng)進(jìn)行大優(yōu)化，我們就趁機(jī)將積分系統(tǒng)進(jìn)行改造然痊，是我們的第二優(yōu)先級分離出來的服務(wù)至朗。
前置服務(wù)，前置服務(wù)一般為服務(wù)的接入或者輸出服務(wù)剧浸，比如網(wǎng)站的前端服務(wù)锹引、app的服務(wù)接口這類，這是我們第三優(yōu)先級分離出來的服務(wù)唆香。
組合服務(wù)嫌变，組合服務(wù)就是涉及到了具體的業(yè)務(wù)，比如買標(biāo)過程躬它，需要調(diào)用很多垂直的業(yè)務(wù)服務(wù)腾啥，這類的服務(wù)我們一般放到最后再進(jìn)行微服務(wù)化架構(gòu)來改造，因為這類服務(wù)最為復(fù)雜，除非涉及到大的業(yè)務(wù)邏輯變更碑宴，我們是不會輕易進(jìn)行遷移软啼。
在這四類服務(wù)之外，新上線的業(yè)務(wù)全部使用Sprng Boot/Cloud這套技術(shù)棧延柠。就這樣祸挪，我們從開源項目云收藏開始，上線幾個Spring Boot項目贞间，到現(xiàn)在公司絕大部分的項目都是在Spring Cloud這個架構(gòu)體系中贿条。
經(jīng)驗和教訓(xùn)
架構(gòu)演化的步驟
在確定使用Spring Boot/Cloud這套技術(shù)棧進(jìn)行微服務(wù)改造之前，先梳理平臺的服務(wù)增热，對不同的服務(wù)進(jìn)行分類整以，以確認(rèn)演化的節(jié)奏。
先讓團(tuán)隊熟悉Spring Boot技術(shù)峻仇，并且優(yōu)先在基礎(chǔ)服務(wù)上進(jìn)行技術(shù)改造公黑，推動改動后的項目投產(chǎn)上線
當(dāng)團(tuán)隊熟悉Spring Boot之后，再推進(jìn)使用Spring Cloud對原有的項目進(jìn)行改造摄咆。
在進(jìn)行微服務(wù)改造過程中凡蚜，優(yōu)先應(yīng)用于新業(yè)務(wù)系統(tǒng)，前期可以只是少量的項目進(jìn)行了微服務(wù)化改造吭从，隨著大家對技術(shù)的熟悉度增加朝蜘，可以加快加大微服務(wù)改造的范圍
傳統(tǒng)項目和微服務(wù)項目共存是一個很常見的情況，除非公司業(yè)務(wù)有大的變化涩金，不建議直接遷移核心項目谱醇。
服務(wù)拆分原則
服務(wù)拆分有以下幾個原則和大家分享
橫向拆分。按照不同的業(yè)務(wù)域進(jìn)行拆分步做，例如訂單副渴、營銷、風(fēng)控全度、積分資源等佳晶。形成獨(dú)立的業(yè)務(wù)領(lǐng)域微服務(wù)集群。
縱向拆分讼载。把一個業(yè)務(wù)功能里的不同模塊或者組件進(jìn)行拆分轿秧。例如把公共組件拆分成獨(dú)立的原子服務(wù)，下沉到底層咨堤，形成相對獨(dú)立的原子服務(wù)層菇篡。這樣一縱一橫，就可以實(shí)現(xiàn)業(yè)務(wù)的服務(wù)化拆分一喘。
要做好微服務(wù)的分層：梳理和抽取核心應(yīng)用驱还、公共應(yīng)用嗜暴，作為獨(dú)立的服務(wù)下沉到核心和公共能力層，逐漸形成穩(wěn)定的服務(wù)中心议蟆，使前端應(yīng)用能更快速的響應(yīng)多變的市場需求
服務(wù)拆分是越小越好嗎闷沥？微服務(wù)的大與小是相對的。比如在初期咐容，我們把交易拆分為一個微服務(wù)舆逃，但是隨著業(yè)務(wù)量的增大，可能一個交易系統(tǒng)已經(jīng)慢慢變得很大戳粒，并且并發(fā)流量也不小路狮，為了支撐更多的交易量，我會把交易系統(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ù)有一段時間了锰悼，這種開發(fā)模式和傳統(tǒng)的開發(fā)模式對比，有很大的不同团赏。
分工不同，以前我們可能是一個一個模塊耐薯，現(xiàn)在可能是一人一個系統(tǒng)舔清。
架構(gòu)不同，服務(wù)的拆分是一個技術(shù)含量很高的問題曲初，拆分是否合理對以后發(fā)展影響巨大体谒。
部署方式不同，如果還像以前一樣部署估計累死了臼婆，自動化運(yùn)維不可不上抒痒。
容災(zāi)不同，好的微服務(wù)可以隔離故障避免服務(wù)整體down掉颁褂，壞的微服務(wù)設(shè)計仍然可以因為一個子服務(wù)出現(xiàn)問題導(dǎo)致連鎖反應(yīng)故响。
給數(shù)據(jù)庫帶來的挑戰(zhàn)
每個微服務(wù)都有自己獨(dú)立的數(shù)據(jù)庫，那么后臺管理的聯(lián)合查詢怎么處理颁独？這應(yīng)該是大家會普遍遇到的一個問題彩届，有三種處理方案。
1）嚴(yán)格按照微服務(wù)的劃分來做誓酒，微服務(wù)相互獨(dú)立樟蠕，各微服務(wù)數(shù)據(jù)庫也獨(dú)立，后臺需要展示數(shù)據(jù)時，調(diào)用各微服務(wù)的接口來獲取對應(yīng)的數(shù)據(jù)寨辩，再進(jìn)行數(shù)據(jù)處理后展示出來吓懈，這是標(biāo)準(zhǔn)的用法，也是最麻煩的用法靡狞。
- 將業(yè)務(wù)高度相關(guān)的表放到一個庫中耻警，將業(yè)務(wù)關(guān)系不是很緊密的表嚴(yán)格按照微服務(wù)模式來拆分，這樣既可以使用微服務(wù)耍攘，也避免了數(shù)據(jù)庫分散導(dǎo)致后臺系統(tǒng)統(tǒng)計功能難以實(shí)現(xiàn)榕栏，是一個折中的方案。
3）數(shù)據(jù)庫嚴(yán)格按照微服務(wù)的要求來切分蕾各，以滿足業(yè)務(wù)高并發(fā)扒磁，實(shí)時或者準(zhǔn)實(shí)時將各微服務(wù)數(shù)據(jù)庫數(shù)據(jù)同步到NoSQL數(shù)據(jù)庫中，在同步的過程中進(jìn)行數(shù)據(jù)清洗式曲，用來滿足后臺業(yè)務(wù)系統(tǒng)的使用妨托，推薦使用MongoDB、HBase等吝羞。
三種方案在不同的公司我都使用過兰伤，第一種方案適合業(yè)務(wù)較為簡單的小公司；第二種方案钧排，適合在原有系統(tǒng)之上敦腔，慢慢演化為微服務(wù)架構(gòu)的公司；第三種適合大型高并發(fā)的互聯(lián)網(wǎng)公司恨溜。
微服務(wù)的經(jīng)驗和建議
1符衔、建議盡量不要使用Jsp，頁面開發(fā)推薦使用Thymeleaf糟袁。Web項目建議獨(dú)立部署Tomcat判族，不要使用內(nèi)嵌的Tomcat，內(nèi)嵌Tomcat部署Jsp項目會偶現(xiàn)龜速訪問的情況项戴。
2形帮、服務(wù)編排是個好東西，主要的作用是減少項目中的相互依賴周叮。比如現(xiàn)在有項目a調(diào)用項目b辩撑，項目b調(diào)用項目c...一直到h，是一個調(diào)用鏈仿耽，那么項目上線的時候需要先更新最底層的h再更新g...更新c更新b最后是更新項目a槐臀。這只是這一個調(diào)用鏈，在復(fù)雜的業(yè)務(wù)中有非常多的調(diào)用氓仲，如果要記住每一個調(diào)用鏈對開發(fā)運(yùn)維人員來說就是災(zāi)難水慨。
有這樣一個好辦法可以盡量的減少項目的相互依賴得糜，就是服務(wù)編排，一個核心的業(yè)務(wù)處理項目晰洒，負(fù)責(zé)和各個微服務(wù)打交道朝抖。比如之前是a調(diào)用b，b掉用c谍珊，c調(diào)用d治宣，現(xiàn)在統(tǒng)一在一個核心項目W中來處理，W服務(wù)使用a的時候去調(diào)用b砌滞，使用b的時候W去調(diào)用c侮邀，舉個例子：在第三方支付業(yè)務(wù)中，有一個核心支付項目是服務(wù)編排贝润，負(fù)責(zé)處理支付的業(yè)務(wù)邏輯绊茧，W項目使用商戶信息的時候就去調(diào)用“商戶系統(tǒng)”，需要校驗設(shè)備的時候就去調(diào)用“終端系統(tǒng)”打掘，需要風(fēng)控的時候就調(diào)用“風(fēng)控系統(tǒng)”华畏，各個項目需要的依賴參數(shù)都由W來做主控。以后項目部署的時候尊蚁，只需要最后啟動服務(wù)編排項目即可亡笑。
3、不要為了追求技術(shù)而追求技術(shù)横朋，確定進(jìn)行微服務(wù)架構(gòu)改造之前仑乌，需要考慮以下幾方面的因素：
1）團(tuán)隊的技術(shù)人員是否已經(jīng)具備相關(guān)技術(shù)基礎(chǔ)。
2）公司業(yè)務(wù)是否適合進(jìn)行微服務(wù)化改造琴锭，并不是所有的平臺都適合進(jìn)行微服務(wù)化改造晰甚，比如：傳統(tǒng)行業(yè)有很多復(fù)雜垂直的業(yè)務(wù)系統(tǒng)。
3）Spring Cloud生態(tài)的技術(shù)有很多祠够，并不是每一種技術(shù)方案都需要用上，適合自己的才是最好的粪牲。
總結(jié)
Spring Cloud對于中小型互聯(lián)網(wǎng)公司來說是一種福音古瓤，因為這類公司往往沒有實(shí)力或者沒有足夠的資金投入去開發(fā)自己的分布式系統(tǒng)基礎(chǔ)設(shè)施，使用Spring Cloud一站式解決方案能在從容應(yīng)對業(yè)務(wù)發(fā)展的同時大大減少開發(fā)成本腺阳。同時落君，隨著近幾年微服務(wù)架構(gòu)和Docker容器概念的火爆，也會讓Spring Cloud在未來越來越“云”化的軟件開發(fā)風(fēng)格中立有一席之地亭引，尤其是在目前五花八門的分布式解決方案中提供了標(biāo)準(zhǔn)化的绎速、全站式的技術(shù)方案，意義可能會堪比當(dāng)前Servlet規(guī)范的誕生焙蚓，有效推進(jìn)服務(wù)端軟件系統(tǒng)技術(shù)水平的進(jìn)步纹冤。
