一、傳統(tǒng)的可擴(kuò)展性架構(gòu)之分層架構(gòu)與SOA架構(gòu)

1镇饮、分層架構(gòu)

（1）概念

• 分層架構(gòu)是很常見的架構(gòu)模式蜓竹，它也叫 N 層架構(gòu)，通常情況下，N 至少是 2 層俱济。例如嘶是，C/S 架構(gòu)、B/S 架構(gòu)蛛碌。常見的是 3 層架構(gòu)（例如聂喇，MVC、MVP 架構(gòu)）左医、4 層架構(gòu)授帕，5 層架構(gòu)的比較少見，一般是比較復(fù)雜的系統(tǒng)才會(huì)達(dá)到或者超過 5 層浮梢，比如操作系統(tǒng)內(nèi)核架構(gòu)跛十。
• 分層架構(gòu)之所以能夠較好地支撐系統(tǒng)擴(kuò)展，本質(zhì)在于隔離關(guān)注點(diǎn)（separation of concerns）秕硝，即每個(gè)層中的組件只會(huì)處理本層的邏輯芥映。分層時(shí)要保證層與層之間的依賴是穩(wěn)定的，才能真正支撐快速擴(kuò)展远豺。

（2）特點(diǎn)

1奈偏、分層架構(gòu)設(shè)計(jì)最核心的一點(diǎn)就是需要保證各層之間的差異足夠清晰，邊界足夠明顯躯护，讓人看到架構(gòu)圖后就能看懂整個(gè)架構(gòu)惊来，這也是分層不能分太多層的原因。
2棺滞、分層結(jié)構(gòu)的另外一個(gè)特點(diǎn)就是層層傳遞裁蚁，也就是說一旦分層確定，整個(gè)業(yè)務(wù)流程是按照層進(jìn)行依次傳遞的继准，不能在層之間進(jìn)行跳躍

2枉证、SOA架構(gòu)

SOA架構(gòu)圖

（1）背景

SOA 出現(xiàn) 的背景是企業(yè)內(nèi)部的 IT 系統(tǒng)重復(fù)建設(shè)且效率低下:企業(yè)各部門有獨(dú)立的 IT 系統(tǒng)，比如人力資源系統(tǒng)移必、財(cái)務(wù)系統(tǒng)室谚、銷售系統(tǒng)，這些系統(tǒng)可能都涉及人員管理崔泵，各 IT 系統(tǒng)都需要重復(fù)開發(fā)人員管理的功能秒赤。1、各個(gè)獨(dú)立的 IT 系統(tǒng)可能采購于不同的供應(yīng)商憎瘸，實(shí)現(xiàn)技術(shù)不同入篮，企業(yè)自己也不太可能基于這些系統(tǒng)進(jìn)行重構(gòu)。2含思、隨著業(yè)務(wù)的發(fā)展崎弃，復(fù)雜度越來越高甘晤，更多的流程和業(yè)務(wù)需要多個(gè) IT 系統(tǒng)合作完成/3、由于各個(gè)獨(dú)立的 IT 系統(tǒng)沒有標(biāo)準(zhǔn)的實(shí)現(xiàn)方式,每次開發(fā)新的流程和業(yè)務(wù)饲做，都需要協(xié)調(diào)大量的 IT 系統(tǒng)线婚，同時(shí)定制開發(fā)，效率很低盆均。

（2）SOA需要關(guān)注的三個(gè)點(diǎn)

• 服務(wù)：所有業(yè)務(wù)功能都是一項(xiàng)服務(wù)塞弊，服務(wù)就意味著要對(duì)外提供開放的能力，當(dāng)其他系統(tǒng)需要使用這項(xiàng)功能時(shí)泪姨，無須定制化開發(fā)游沿。
• ESB企業(yè)服務(wù)總線：因?yàn)楦鱾€(gè)獨(dú)立的服務(wù)是異構(gòu)的，如果沒有統(tǒng)一的標(biāo)準(zhǔn)肮砾，則各個(gè)異構(gòu)系統(tǒng)對(duì)外提供的接口是各式各樣的诀黍。SOA 使用 ESB 來屏蔽異構(gòu)系統(tǒng)對(duì)外提供各種不同的接口方式，以此來達(dá)到服務(wù)間高效的互聯(lián)互通仗处。
• 松耦合：松耦合的目的是減少各個(gè)服務(wù)間的依賴和互相影響

（3）SOA總結(jié)

• SOA 解決了傳統(tǒng) IT 系統(tǒng)重復(fù)建設(shè)和擴(kuò)展效率低的問題眯勾，但其本身也引入了更多的復(fù)雜性。SOA 最廣為人詬病的就是 ESB婆誓，ESB 需要實(shí)現(xiàn)與各種系統(tǒng)間的協(xié)議轉(zhuǎn)換吃环、數(shù)據(jù)轉(zhuǎn)換、透明的動(dòng)態(tài)路由等功能洋幻。當(dāng)ESB的出現(xiàn)是為了適應(yīng)當(dāng)前的架構(gòu)郁轻，企業(yè)在應(yīng)用 SOA 時(shí)，各種異構(gòu)的 IT 系統(tǒng)都已經(jīng)存在很多年了文留，完全重寫或者按照統(tǒng)一標(biāo)準(zhǔn)進(jìn)行改造的成本是非常大的好唯，只能通過 ESB 方式去適配已經(jīng)存在的各種異構(gòu)系統(tǒng)。
• SOA之所以會(huì)出現(xiàn)可以是傳統(tǒng)互聯(lián)網(wǎng)歷史遺留問題導(dǎo)致的厂庇，從原有復(fù)雜的系統(tǒng)進(jìn)行拆分為服務(wù)渠啊，然后通過ESB來統(tǒng)一管理输吏，達(dá)到服務(wù)之間的聯(lián)通权旷。

（4）思考：為啥SOA不適合互聯(lián)網(wǎng)？

• 1贯溅、首先從互聯(lián)網(wǎng)和傳統(tǒng)企業(yè)特點(diǎn)說起拄氯。互聯(lián)網(wǎng)企業(yè)的特點(diǎn)就是小它浅，新译柏，快。沒有歷史包袱姐霍，變化快鄙麦，大部分是從單體演進(jìn)到分布式典唇，技術(shù)棧一脈相承，而到了分布式之后胯府，面對(duì)不斷的耦合介衔，系統(tǒng)復(fù)雜度的陡增，這時(shí)一個(gè)soa的特例微服務(wù)出現(xiàn)了骂因。也就是說需要更加細(xì)致的拆分炎咖。
• 2、然后從SOA特點(diǎn)說起：soa是集成的思想寒波，是解決服務(wù)孤島打通鏈條乘盼，是無奈之舉。esb集中化的管理帶來了性能不佳俄烁，厚重等問題绸栅。也無法快速擴(kuò)展。不適合互聯(lián)網(wǎng)的業(yè)務(wù)特點(diǎn)页屠；

二阴幌、微服務(wù)基本概念

1、歷史

2005 年：Dr. Peter Rodgers 在 Web Services Edge 大會(huì)上提出了“Micro-Web-Services”的概念卷中。
2011 年：一個(gè)軟件架構(gòu)工作組使用了“microservice”一詞來描述一種架構(gòu)模式矛双。
2012 年：同樣是這個(gè)架構(gòu)工作組，正式確定用“microservice”來代表這種架構(gòu)蟆豫。
2012 年：ThoughtWorks 的 James Lewis 針對(duì)微服務(wù)概念在 QCon San Francisco 2012 發(fā)表了演講议忽。
2014 年：James Lewis 和 Martin Fowler 合寫了關(guān)于微服務(wù)的一篇學(xué)術(shù)性的文章，詳細(xì)闡述了微服務(wù)十减。推動(dòng)了微服務(wù)的發(fā)展

2栈幸、微服務(wù)和SOA關(guān)系

• 對(duì)于微服務(wù)和SOA，通嘲锉伲看起來二者很相似速址，并沒有什么實(shí)質(zhì)上的不同，因此往往會(huì)由下列錯(cuò)誤的偏見：

觀點(diǎn)一：微服務(wù)是 SOA 的實(shí)現(xiàn)方式由驹，可以這么說微服務(wù)就是更細(xì)粒度的 SOA
觀點(diǎn)二：微服務(wù)是去掉 ESB 后的 SOA芍锚。傳統(tǒng) SOA 架構(gòu)最廣為人詬病的就是龐大、復(fù)雜蔓榄、低效的 ESB并炮，因此將 ESB 去掉，改為輕量級(jí)的 HTTP 實(shí)現(xiàn)甥郑，就是微服務(wù)逃魄。

• 實(shí)際上，微服務(wù)是一種和 SOA 相似但本質(zhì)上不同的架構(gòu)理念澜搅，相似就是兩者都關(guān)注“服務(wù)”伍俘，都是通過服務(wù)的拆分來解決可擴(kuò)展性問題邪锌。本質(zhì)上不同的地方在于幾個(gè)核心理念的差異：是否有 ESB、服務(wù)的粒度癌瘾、架構(gòu)設(shè)計(jì)的目標(biāo)等秃流。為什么這么說呢？

1柳弄、服務(wù)粒度：整體上來說舶胀，SOA 的服務(wù)粒度要粗一些，而微服務(wù)的服務(wù)粒度要細(xì)一些
2碧注、服務(wù)通信：SOA 采用了 ESB 作為服務(wù)間通信的關(guān)鍵組件嚣伐，負(fù)責(zé)服務(wù)定義、服務(wù)路由萍丐、消息轉(zhuǎn)換轩端、消息傳遞，總體上是重量級(jí)的實(shí)現(xiàn)逝变。微服務(wù)推薦使用統(tǒng)一的協(xié)議和格式基茵，例如，RESTful 協(xié)議壳影、RPC 協(xié)議拱层，無須 ESB 這樣的重量級(jí)實(shí)現(xiàn)。
3宴咧、服務(wù)交付：SOA 對(duì)服務(wù)的交付并沒有特殊要求根灯，因?yàn)?SOA 更多考慮的是兼容已有的系統(tǒng)；微服務(wù)的架構(gòu)理念要求“快速交付”掺栅，相應(yīng)地要求采取自動(dòng)化測(cè)試烙肺、持續(xù)集成、自動(dòng)化部署等敏捷開發(fā)相關(guān)的最佳實(shí)踐氧卧。
4桃笙、應(yīng)用場(chǎng)景：（1）SOA 更加適合于龐大、復(fù)雜沙绝、異構(gòu)的企業(yè)級(jí)系統(tǒng)搏明，這也是 SOA 誕生的背景。這類系統(tǒng)的典型特征就是很多系統(tǒng)已經(jīng)發(fā)展多年宿饱，采用不同的企業(yè)級(jí)技術(shù)熏瞄，有的是內(nèi)部開發(fā)的脚祟，有的是外部購買的谬以，無法完全推倒重來或者進(jìn)行大規(guī)模的優(yōu)化和重構(gòu)。因?yàn)槌杀竞陀绊懱笥勺溃荒懿捎眉嫒莸姆绞竭M(jìn)行處理为黎，而承擔(dān)兼容任務(wù)的就是 ESB邮丰。（傳統(tǒng)大型企業(yè)）（2）微服務(wù)更加適合于快速、輕量級(jí)铭乾、基于 Web 的互聯(lián)網(wǎng)系統(tǒng)剪廉，這類系統(tǒng)業(yè)務(wù)變化快，需要快速嘗試炕檩、快速交付斗蒋；同時(shí)基本都是基于 Web，雖然開發(fā)技術(shù)可能差異很大（例如笛质，Java泉沾、C++、.NET 等）妇押，但對(duì)外接口基本都是提供 HTTP RESTful 風(fēng)格的接口跷究，無須考慮在接口層進(jìn)行類似 SOA 的 ESB 那樣的處理。（互聯(lián)網(wǎng)）

3敲霍、到底什么是微服務(wù)

• 微服務(wù)架構(gòu)風(fēng)格是一類將單一應(yīng)用程序作為由眾多小型服務(wù)構(gòu)成之套件加以開發(fā)的方式俊马，其中各項(xiàng)服務(wù)都擁有自己的進(jìn)程并利用輕量化機(jī)制（通常為HTTP源API）實(shí)現(xiàn)通信。這些服務(wù)圍繞業(yè)務(wù)功能建立而成肩杈，且憑借自動(dòng)化部署機(jī)制實(shí)現(xiàn)獨(dú)立部署柴我。

4、微服務(wù)的特點(diǎn)

• （1）應(yīng)用程序邏輯分為明確定義的職責(zé)范圍的粒度組件扩然，這些組件相互協(xié)調(diào)提供解決方案（粒度細(xì)屯换、單一職責(zé)）
• （2）每一個(gè)組件都有一個(gè)小的職責(zé)領(lǐng)域，可以完全部署与学，也就是說一個(gè)服務(wù)可以跨越多個(gè)應(yīng)用程序復(fù)用（獨(dú)立部署和維護(hù)）
• （3）服務(wù)之間通信基于一些基本的原則彤悔，比如服務(wù)采用http+json這樣的輕量級(jí)通信協(xié)議，在不同服務(wù)之間進(jìn)行數(shù)據(jù)交換索守。這樣不同服務(wù)可以使用不同的技術(shù)棧晕窑，互不影響（采用輕量級(jí)的通信協(xié)議作為通信原則、松耦合）
• （4）拆分為微服務(wù)之后卵佛，服務(wù)的數(shù)量變多杨赤，因此需要有統(tǒng)一的服務(wù)治理平臺(tái)，來對(duì)各個(gè)服務(wù)進(jìn)行管理截汪。（服務(wù)可治理疾牲，可管控）

5、微服務(wù)架構(gòu)的一些通用特性

• 根據(jù)MartinFowler的分析衙解，微服務(wù)架構(gòu)有以下的一些通用特性：

1阳柔、通過服務(wù)實(shí)現(xiàn)應(yīng)用的組件化（按功能拆分、可獨(dú)立部署和維護(hù)）
2蚓峦、圍繞業(yè)務(wù)能力組織服務(wù)（這并不一定舌剂，國外是團(tuán)隊(duì)前后端搭配济锄，但是中國基本是按不同技術(shù)棧劃分團(tuán)隊(duì)）
3、產(chǎn)品而非項(xiàng)目模式
4霍转、“去中心化”數(shù)據(jù)和治理
5荐绝、基礎(chǔ)設(shè)施自動(dòng)化
6、故障處理設(shè)計(jì)
7避消、演進(jìn)式的設(shè)計(jì)

參考：解析微服務(wù)

6低滩、微服務(wù)與云

（1）云相關(guān)概念

• 基礎(chǔ)設(shè)施即服務(wù)IaaS
• 平臺(tái)即服務(wù)PaaS
• 軟件即服務(wù)SaaS

（2）為啥微服務(wù)需要云（代補(bǔ)充）

• 微服務(wù)的一個(gè)核心就是每一個(gè)服務(wù)最終會(huì)被打包部署為離散的獨(dú)立制品，基本上企業(yè)部署軟件會(huì)用以下方式進(jìn)行岩喷，而基于云部署能達(dá)到服務(wù)的快速上下線操作委造，伸縮性和靈活性得到很大的提高，同時(shí)從成本上也更加可控制均驶。

物理服務(wù)器：不易于擴(kuò)展昏兆，不靈活，成本高
虛擬機(jī)鏡像：虛擬機(jī)是云供應(yīng)商的靈魂妇穴，微服務(wù)可以打包在虛擬機(jī)鏡像中爬虱，然后開發(fā)人員在IaaS私有或者公有云中快速部署和啟動(dòng)服務(wù)的多個(gè)實(shí)例
虛擬容器：是在虛擬機(jī)鏡像上部署微服務(wù)的自然延伸，也就是許多的開發(fā)人員不是將微服務(wù)直接部署到完整的虛擬機(jī)上腾它，而是將docker容器部署到云端跑筝，虛擬容器在虛擬機(jī)內(nèi)運(yùn)行。

• 同時(shí)可以利用云廠商提供的各種服務(wù)和工具瞒滴，對(duì)于微服務(wù)開發(fā)是很有利的

7曲梗、微服務(wù)與devops

• 從運(yùn)維角度看微服務(wù)如何打包、部署和監(jiān)控是至關(guān)重要的妓忍。
  上一篇文章中主要講了微服務(wù)相關(guān)的一些基本概念虏两，以及與傳統(tǒng)SOA的區(qū)別，這一篇文章主要講微服務(wù)架構(gòu)設(shè)計(jì)中需要注意的問題和最佳實(shí)踐世剖，以及使用spring家族成員構(gòu)建微服務(wù)的一些知識(shí)定罢。

三、微服務(wù)設(shè)計(jì)帶來的問題及需要注意的地方

1旁瘫、微服務(wù)帶來的缺點(diǎn)

（1）運(yùn)維開銷及成本增加

整體應(yīng)用可能只需部署至一小片應(yīng)用服務(wù)區(qū)集群祖凫，而微服務(wù)架構(gòu)可能變成需要構(gòu)建/測(cè)試/部署/運(yùn)行數(shù)十個(gè)獨(dú)立的服務(wù)，并可能需要支持多種語言和環(huán)境酬凳。這導(dǎo)致一個(gè)整體式系統(tǒng)如果由20個(gè)微服務(wù)組成惠况，可能需要40~60個(gè)進(jìn)程。

（2）必須有堅(jiān)實(shí)的DevOps開發(fā)運(yùn)維一體化技能

開發(fā)人員需要熟知運(yùn)維與投產(chǎn)環(huán)境宁仔，開發(fā)人員也需要掌握必要的數(shù)據(jù)存儲(chǔ)技術(shù)如NoSQL稠屠，具有較強(qiáng)DevOps技能的人員比較稀缺，會(huì)帶來招聘人才方面的挑戰(zhàn)。

（3）隱式接口及接口匹配問題完箩，帶來發(fā)布風(fēng)險(xiǎn)

把系統(tǒng)分為多個(gè)協(xié)作組件后會(huì)產(chǎn)生新的接口赐俗，這意味著簡(jiǎn)單的交叉變化可能需要改變?cè)S多組件拉队，并需協(xié)調(diào)一起發(fā)布弊知。在實(shí)際環(huán)境中，一個(gè)新品發(fā)布可能被迫同時(shí)發(fā)布大量服務(wù)粱快，由于集成點(diǎn)的大量增加秩彤，微服務(wù)架構(gòu)會(huì)有更高的發(fā)布風(fēng)險(xiǎn)。

（4）代碼重復(fù)

某些底層功能需要被多個(gè)服務(wù)所用事哭，為了避免將“同步耦合引入到系統(tǒng)中”漫雷，有時(shí)需要向不同服務(wù)添加一些代碼，這就會(huì)導(dǎo)致代碼重復(fù)鳍咱。

（5）分布式系統(tǒng)的復(fù)雜性

作為一種分布式系統(tǒng)降盹，微服務(wù)引入了復(fù)雜性和其他若干問題，例如網(wǎng)絡(luò)延遲谤辜、容錯(cuò)性蓄坏、消息序列化、不可靠的網(wǎng)絡(luò)丑念、異步機(jī)制涡戳、版本化、差異化的工作負(fù)載等脯倚，開發(fā)人員需要考慮以上的分布式系統(tǒng)問題渔彰。

（6）可測(cè)性的挑戰(zhàn)

在動(dòng)態(tài)環(huán)境下服務(wù)間的交互會(huì)產(chǎn)生非常微妙的行為，難以可視化及全面測(cè)試推正。經(jīng)典微服務(wù)往往不太重視測(cè)試恍涂，更多的是通過監(jiān)控發(fā)現(xiàn)生產(chǎn)環(huán)境的異常，進(jìn)而快速回滾或采取其他必要的行動(dòng)植榕。但對(duì)于特別在意風(fēng)險(xiǎn)規(guī)避監(jiān)管或投產(chǎn)環(huán)境錯(cuò)誤會(huì)產(chǎn)生顯著影響的場(chǎng)景下需要特別注意乳丰。

2、微服務(wù)架構(gòu)設(shè)計(jì)過程中需要注意的點(diǎn)

（1）服務(wù)劃分過細(xì)内贮，服務(wù)間關(guān)系復(fù)雜
（2）服務(wù)數(shù)量太多产园，團(tuán)隊(duì)效率急劇下降
（3）調(diào)用鏈太長(zhǎng)，性能下降
（4）調(diào)用鏈太長(zhǎng)夜郁，問題定位困難

（5）沒有自動(dòng)化支撐什燕，無法快速交付（自動(dòng)化測(cè)試、自動(dòng)化部署竞端、自動(dòng)化監(jiān)控等）
（6）沒有服務(wù)治理屎即，微服務(wù)數(shù)量多了后管理混亂（服務(wù)路由、服務(wù)故障隔離、服務(wù)注冊(cè)與發(fā)現(xiàn)等等）
（7）其他

• 總結(jié)微服務(wù)設(shè)計(jì)中需要避免如下幾種情況技俐。1乘陪、微服務(wù)拆分過細(xì)，過分強(qiáng)調(diào)“small2雕擂、微服務(wù)基礎(chǔ)設(shè)施不健全啡邑，忽略了“automated”3、微服務(wù)并不輕量級(jí)井赌，規(guī)模大了后谤逼，“l(fā)ightweight”不再適應(yīng)。

四仇穗、微服務(wù)架構(gòu)最佳實(shí)踐

1流部、方法篇

（1）服務(wù)粒度的劃分

服務(wù)粒度的劃分是伴隨著架構(gòu)演進(jìn)進(jìn)行的，需要考慮當(dāng)前的人力纹坐、物力等來有效的統(tǒng)籌枝冀，在項(xiàng)目的初期可以把服務(wù)的粒度設(shè)計(jì)大一點(diǎn)，隨著項(xiàng)目的不斷壯大耘子，團(tuán)隊(duì)的規(guī)模不斷變大果漾，可以對(duì)現(xiàn)有的粗粒度服務(wù)進(jìn)行有效的拆分，逐步的向細(xì)粒度服務(wù)發(fā)展拴还。

（2）拆分

在進(jìn)行服務(wù)拆分的時(shí)候是有張可尋的跨晴，需要根據(jù)自己的項(xiàng)目進(jìn)行設(shè)計(jì)，并不能一味的按功能片林、按大小端盆、按人力等去拆分》逊猓基本的拆分可以按如下的幾種方式進(jìn)行焕妙。

1、基于業(yè)務(wù)邏輯進(jìn)行拆分弓摘。這是最常見的一種拆分方式焚鹊，將系統(tǒng)中的業(yè)務(wù)模塊按照職責(zé)范圍識(shí)別出來，每個(gè)單獨(dú)的業(yè)務(wù)模塊拆分為一個(gè)獨(dú)立的服務(wù)韧献∧┗迹基于業(yè)務(wù)邏輯拆分雖然看起來很直觀，但在實(shí)踐過程中最常見的一個(gè)問題就是團(tuán)隊(duì)成員對(duì)于“職責(zé)范圍”的理解差異很大锤窑，因此根據(jù)業(yè)務(wù)拆分需要權(quán)衡當(dāng)前項(xiàng)目組的情況璧针。
2、基于可擴(kuò)展拆分渊啰。將系統(tǒng)中的業(yè)務(wù)模塊按照穩(wěn)定性排序探橱，將已經(jīng)成熟和改動(dòng)不大的服務(wù)拆分為穩(wěn)定服務(wù)申屹，將經(jīng)常變化和迭代的服務(wù)拆分為變動(dòng)服務(wù)。穩(wěn)定的服務(wù)粒度可以粗一些隧膏，即使邏輯上沒有強(qiáng)關(guān)聯(lián)的服務(wù)哗讥，也可以放在同一個(gè)子系統(tǒng)中，例如將“日志服務(wù)”和“升級(jí)服務(wù)”放在同一個(gè)子系統(tǒng)中胞枕；不穩(wěn)定的服務(wù)粒度可以細(xì)一些杆煞，但也不要太細(xì)，始終記住要控制服務(wù)的總數(shù)量曲稼。這樣拆分主要是為了提升項(xiàng)目快速迭代的效率索绪，避免在開發(fā)的時(shí)候湖员，不小心影響了已有的成熟功能導(dǎo)致線上問題贫悄。
3、基于可靠性拆分娘摔。將系統(tǒng)中的業(yè)務(wù)模塊按照優(yōu)先級(jí)排序窄坦，將可靠性要求高的核心服務(wù)和可靠性要求低的非核心服務(wù)拆分開來，然后重點(diǎn)保證核心服務(wù)的高可用凳寺。這樣拆分帶來下面幾個(gè)好處：（避免非核心服務(wù)故障影響核心服務(wù)鸭津、核心服務(wù)高可用方案可以更簡(jiǎn)單、能夠降低高可用成本）
4肠缨、基于性能拆分逆趋。基于性能拆分和基于可靠性拆分類似晒奕，將性能要求高或者性能壓力大的模塊拆分出來闻书，避免性能壓力大的服務(wù)影響其他服務(wù)。常見的拆分方式和具體的性能瓶頸有關(guān)脑慧，可以拆分 Web 服務(wù)魄眉、數(shù)據(jù)庫、緩存等闷袒。

2坑律、基礎(chǔ)設(shè)施篇

大部分人主要關(guān)注的是微服務(wù)的“small”和“l(fā)ightweight”特性，但實(shí)際上真正決定微服務(wù)成敗的囊骤，恰恰是那個(gè)被大部分人都忽略的“automated”晃择。也就是說基礎(chǔ)設(shè)施在微服務(wù)中占據(jù)的主導(dǎo)作用。如果“automated”相關(guān)的基礎(chǔ)設(shè)施不健全也物，那微服務(wù)就是焦油坑宫屠，讓研發(fā)、測(cè)試焦除、運(yùn)維陷入微服務(wù)的各種陷阱中激况。

微服務(wù)基礎(chǔ)設(shè)施

上圖是微服務(wù)架構(gòu)中涉及的基礎(chǔ)設(shè)施，可以看出建設(shè)完善的微服務(wù)基礎(chǔ)設(shè)施是一項(xiàng)龐大的工程，但是并不是中小企業(yè)就不能玩轉(zhuǎn)微服務(wù)乌逐。第一個(gè)原因是已經(jīng)有開源的微服務(wù)基礎(chǔ)設(shè)施全家桶了疆虚，例如大名鼎鼎的 Spring Cloud 項(xiàng)目，涵蓋了服務(wù)發(fā)現(xiàn)迎献、服務(wù)路由只嚣、網(wǎng)關(guān)、配置中心等功能洛波；第二個(gè)原因是如果微服務(wù)的數(shù)量并不是很多的話胰舆，并不是每個(gè)基礎(chǔ)設(shè)施都是必須的。通常情況下蹬挤，可以按照下列的優(yōu)先級(jí)來搭建微服務(wù)的基礎(chǔ)設(shè)施缚窿。

1. 服務(wù)發(fā)現(xiàn)、服務(wù)路由焰扳、服務(wù)容錯(cuò)：這是最基本的微服務(wù)基礎(chǔ)設(shè)施倦零。
2. 接口框架、API 網(wǎng)關(guān)：主要是為了提升開發(fā)效率吨悍，接口框架是提升內(nèi)部服務(wù)的開發(fā)效率扫茅，API 網(wǎng)關(guān)是為了提升與外部服務(wù)對(duì)接的效率。
3. 自動(dòng)化部署育瓜、自動(dòng)化測(cè)試葫隙、配置中心：主要是為了提升測(cè)試和運(yùn)維效率。
4. 服務(wù)監(jiān)控躏仇、服務(wù)跟蹤恋脚、服務(wù)安全：主要是為了進(jìn)一步提升運(yùn)維效率。

五钙态、使用SpringBoot和SpringCloud構(gòu)建微服務(wù)

• 在基于java的應(yīng)用程序構(gòu)建中慧起，spring已經(jīng)成為事實(shí)上的標(biāo)準(zhǔn)開發(fā)框架，spring框架迷人的地方就是能夠與時(shí)俱進(jìn)的進(jìn)行自我改造册倒。隨著發(fā)展蚓挤，spring團(tuán)隊(duì)不僅開發(fā)出了單體應(yīng)用程序模型，還轉(zhuǎn)向了高度分布式的模型驻子，使服務(wù)能夠輕松的部署到云端灿意，典型代表就是springboot和springcloud。
• springboot是對(duì)spring框架理念的重新思考崇呵，雖然springboot包含了spring的核心特性缤剧，但是它剝離了spring中的許多企業(yè)特性，而是提供一個(gè)基于java的域慷、面向REST的微服務(wù)框架荒辕，只是需要簡(jiǎn)單的注解汗销，java開發(fā)者就能快速構(gòu)建一個(gè)可打包和部署的REST微服務(wù)。
• springcloud框架使實(shí)施和部署微服務(wù)到私有云或者公有云變得更加簡(jiǎn)單抵窒，springcloud在一個(gè)公共框架之下封裝了許多流行的云管理微服務(wù)框架弛针，并且讓這些技術(shù)的使用和部署像為代碼添加注解一樣簡(jiǎn)單。

參考：
spring微服務(wù)實(shí)戰(zhàn)
極客時(shí)間-從0開始學(xué)架構(gòu)
極客時(shí)間-從0開始學(xué)微服務(wù)