前情提要：互聯(lián)網(wǎng)架構(gòu)為什么要做服務(wù)化贱迟？
一、互聯(lián)網(wǎng)架構(gòu)為什么要進(jìn)行服務(wù)化-總結(jié)
上一篇和大伙交流了一下絮供，隨著數(shù)據(jù)量衣吠、并發(fā)量、業(yè)務(wù)復(fù)雜度的增長壤靶，互聯(lián)網(wǎng)架構(gòu)會(huì)出現(xiàn)以下問題：
（1）代碼到處拷貝
（2）底層復(fù)雜性擴(kuò)散
（3）基礎(chǔ)庫（so/jar/dll）耦合
（4）SQL質(zhì)量得不到保障缚俏，業(yè)務(wù)相互影響
（5）數(shù)據(jù)庫耦合
“服務(wù)化”是一個(gè)很好的解決上述痛點(diǎn)的方案。
不少評(píng)論也提出了不少有建設(shè)性的觀點(diǎn)贮乳，匯總出來分享給大伙：
@田衛(wèi)同學(xué)提到：
服務(wù)化之后忧换，可能會(huì)引發(fā)分布式事務(wù)的問題，“沒人愿意引入分布式事務(wù)向拆，當(dāng)基于業(yè)務(wù)水平拆分的時(shí)候包雀，要業(yè)務(wù)專家介入，合理拆分服務(wù)化亲铡，以后就服務(wù)內(nèi)高內(nèi)聚，事務(wù)可以保證葡兑，對(duì)于夸服務(wù)調(diào)用奖蔓，通過補(bǔ)償?shù)仁侄危灰罱K一致性就行讹堤，畢竟連現(xiàn)在的銀行轉(zhuǎn)賬都不是強(qiáng)一致性吆鹤。”
如@田衛(wèi)所說洲守，分布式事務(wù)是業(yè)界沒有徹底解決的難題疑务，任何架構(gòu)設(shè)計(jì)都是一個(gè)折衷，吞吐量梗醇？時(shí)延知允？一致性？哪個(gè)是主要矛盾叙谨，優(yōu)先解決哪個(gè)問題温鸽。大數(shù)據(jù)、高并發(fā)手负、業(yè)務(wù)復(fù)雜性是主要矛盾的時(shí)候涤垫，或許“最終一致性”是一個(gè)替代“事務(wù)”更好的，或者說業(yè)務(wù)能夠接受的方案竟终。
@侯滇滇同學(xué)提到：
多了一層服務(wù)層蝠猬，架構(gòu)實(shí)際上是更復(fù)雜了，需要引入一系列機(jī)制對(duì)服務(wù)進(jìn)行管理统捶，RPC服務(wù)化中需要注意：
（1）RPC服務(wù)超時(shí)榆芦，服務(wù)調(diào)用者應(yīng)有一些應(yīng)對(duì)策略柄粹，比如重發(fā)
（2）關(guān)鍵服務(wù)例如支付，要注意冪等性歧杏，因?yàn)橹匕l(fā)會(huì)導(dǎo)致重復(fù)操作
（3）多服務(wù)要考慮并發(fā)操作镰惦，相當(dāng)單服務(wù)的鎖機(jī)制比如JAVA中的synchronized
@黃明同學(xué)提到：
服務(wù)化之后，隨著規(guī)模的擴(kuò)大犬绒，一定要考慮“服務(wù)治理”旺入，否則服務(wù)之間的依賴關(guān)系會(huì)亂成麻
二、互聯(lián)網(wǎng)微服務(wù)架構(gòu)多“微”才適合
大家也都認(rèn)可凯力，隨著數(shù)據(jù)量茵瘾、流量、業(yè)務(wù)復(fù)雜度的提升咐鹤，服務(wù)化架構(gòu)是架構(gòu)演進(jìn)中的必由之路拗秘，今天要討論的話題是：微服務(wù)架構(gòu)多“微”才合適？
【粗粒度：一個(gè)服務(wù)層】
最粗獷的玩法祈惶，所有基礎(chǔ)數(shù)據(jù)的訪問雕旨，都通過一個(gè)service訪問，在業(yè)務(wù)不是特別復(fù)雜的時(shí)候還好捧请，一旦業(yè)務(wù)變復(fù)雜了凡涩，這個(gè)service層會(huì)變得非常重，成為耦合點(diǎn)之一疹蛉，以微信場景為例活箕，假設(shè)有一個(gè)通用的服務(wù)層來訪問基礎(chǔ)數(shù)據(jù)，這個(gè)服務(wù)層可能是這樣的：
有一個(gè)統(tǒng)一的service層可款，用戶信息育韩，好友信息，群組信息闺鲸，消息信息都通過這個(gè)service層來走筋讨。
細(xì)節(jié)：微信單對(duì)單消息是一個(gè)寫多讀少的業(yè)務(wù)，故沒有緩存翠拣。
【一個(gè)子業(yè)務(wù)一個(gè)service】
如果所有的信息存儲(chǔ)都在一個(gè)service里版仔，那么一個(gè)地方出bug，就將影響整個(gè)業(yè)務(wù)误墓，所以更合理的做法是在服務(wù)層進(jìn)行細(xì)分蛮粮，架構(gòu)如何細(xì)分？垂直拆分是個(gè)好的方案谜慌，將子業(yè)務(wù)一個(gè)個(gè)拆出來然想，那么微信的服務(wù)化架構(gòu)或許會(huì)變成這個(gè)樣子：
（1）用戶相關(guān)的子業(yè)務(wù)有user-service
（2）好友相關(guān)的子業(yè)務(wù)有friend-service
（3）群組相關(guān)的子業(yè)務(wù)有g(shù)roup-service
（4）消息相關(guān)的子業(yè)務(wù)有msg-service
這樣的話，一個(gè)service出問題也不會(huì)影響其他service欣范，同時(shí)數(shù)據(jù)層也按照業(yè)務(wù)垂直拆分開了变泄。
服務(wù)粒度變細(xì)之后令哟，出現(xiàn)一個(gè)新的問題，業(yè)務(wù)與服務(wù)的連接關(guān)系變復(fù)雜了妨蛹，有什么好的優(yōu)化方案么屏富？
常見的，加入一個(gè)高可用服務(wù)分發(fā)層集群蛙卤，并在協(xié)議設(shè)計(jì)時(shí)加入服務(wù)號(hào)狠半，可以減少蜘蛛網(wǎng)狀的依賴關(guān)系：
（1）調(diào)用方依賴分發(fā)層，傳入服務(wù)號(hào)
（2）分發(fā)層依賴服務(wù)層颤难，通過服務(wù)號(hào)參數(shù)分發(fā)
【一個(gè)數(shù)據(jù)庫對(duì)應(yīng)一個(gè)service】
數(shù)據(jù)訪問service最初是從DAO/ORM的數(shù)據(jù)訪問需求過來的神年，所以有些公司也有一個(gè)數(shù)據(jù)表一個(gè)service的玩法。
一個(gè)子業(yè)務(wù)對(duì)應(yīng)一個(gè)service的玩法是：
（1）服務(wù)層行嗤，整個(gè)群業(yè)務(wù)是一個(gè)service
（2）存儲(chǔ)層已日，實(shí)際可能對(duì)應(yīng)了群信息、群成員栅屏、群消息等多個(gè)數(shù)據(jù)表
拆分成一個(gè)數(shù)據(jù)表一個(gè)service飘千，則架構(gòu)會(huì)變成這樣：
群信息表，群成員表栈雳，群消息表等各個(gè)數(shù)據(jù)表之間也解耦開了占婉，不會(huì)相互影響了。
【一個(gè)接口對(duì)應(yīng)一個(gè)service】
微服務(wù)架構(gòu)中更極端的甫恩，甚至一個(gè)接口對(duì)應(yīng)一個(gè)微服務(wù)，這樣的話酌予，架構(gòu)就從：
演化為：
（1）修改群信息服務(wù)
（2）增加群信息服務(wù)
（3）獲取群信息服務(wù)
多個(gè)服務(wù)操縱同一個(gè)數(shù)據(jù)表磺箕，使用同一片緩存，每個(gè)接口出問題抛虫，都不會(huì)影響其他接口松靡。
三、粒度粗細(xì)的優(yōu)劣
上文中談到的服務(wù)化與微服務(wù)建椰，不同粒度的服務(wù)化各有什么優(yōu)劣呢雕欺？
總的來說，細(xì)粒度拆分的優(yōu)點(diǎn)有：
（1）服務(wù)都能夠獨(dú)立部署
（2）擴(kuò)容和縮容方便棉姐，有利于提高資源利用率
（3）拆得越細(xì)屠列，耦合相對(duì)會(huì)減小
（4）拆得越細(xì)，容錯(cuò)相對(duì)會(huì)更好伞矩，一個(gè)服務(wù)出問題不影響其他服務(wù)
（5）擴(kuò)展性更好
（6）…
細(xì)粒度拆分的不足也很明顯：
（1）拆得越細(xì)笛洛，系統(tǒng)越復(fù)雜
（2）系統(tǒng)之間的依賴關(guān)系也更復(fù)雜
（3）運(yùn)維復(fù)雜度提升
（4）監(jiān)控更加復(fù)雜
（5）出問題時(shí)定位問題更難
（6）…
關(guān)于微服務(wù)架構(gòu)的“粒度”問題，以及各粒度的優(yōu)劣乃坤，大伙有什么好的看法苛让，歡迎補(bǔ)充沟蔑，建設(shè)性的意見將在后續(xù)文中和大伙share。
四狱杰、結(jié)束的話
聊了許多瘦材，有網(wǎng)友問，筆者對(duì)待服務(wù)化以及微服務(wù)粒度的看法仿畸，個(gè)人覺得食棕，以“子業(yè)務(wù)系統(tǒng)”粒度作為微服務(wù)的單位是比較合適的：
末了，討論完微服務(wù)架構(gòu)的粒度颁湖，后續(xù)文章和大家聊一聊微服務(wù)的最佳實(shí)踐宣蠕，需要什么樣的框架、組件甥捺、技術(shù)能夠?qū)⒎?wù)化在較短的時(shí)間內(nèi)開展起來抢蚀，下周和大伙再聊。
==【完】==
回【無鎖】如何實(shí)現(xiàn)超高并發(fā)的無鎖緩存镰禾？
回【消息】58到家通用實(shí)時(shí)消息平臺(tái)架構(gòu)細(xì)節(jié)
回【機(jī)房】從IDC到云端架構(gòu)遷移之路
回【設(shè)置】線程數(shù)究竟設(shè)多少合理
回【單點(diǎn)】單點(diǎn)系統(tǒng)架構(gòu)的可用性與性能優(yōu)化
回【事務(wù)】多庫多事務(wù)降低數(shù)據(jù)不一致概率
