互聯(lián)網(wǎng)架構(gòu)為什么要做服務(wù)化住练？
服務(wù)化架構(gòu)的演進(jìn)與實(shí)踐
[私密文檔] TC組件
一地啰、接觸的服務(wù)化中間件
MQ
消息系統(tǒng)，使用多種方式來確保消息可靠的生產(chǎn)讲逛、投遞和消費(fèi)亏吝，使得生產(chǎn)者和消費(fèi)者有效解耦，降低了系統(tǒng)復(fù)雜性盏混。
為什么要用消息系統(tǒng)蔚鸥？消息系統(tǒng)沒有提高系統(tǒng)性能（將消費(fèi)者和生產(chǎn)者寫在一起豈不是更快？）许赃，也不是數(shù)據(jù)源（Redis更佳）止喷，而是實(shí)現(xiàn)了生產(chǎn)者和消費(fèi)者的解耦。生產(chǎn)者和消費(fèi)者各司其職混聊，生產(chǎn)者把消息生產(chǎn)好弹谁，至于消息如何交付給消費(fèi)者，這種交付方式是不是會(huì)丟失消息之類的可靠性問題一概不管（這也就是為什么消息隊(duì)列不僅是一個(gè)中間結(jié)果存放區(qū)的原因）。這個(gè)作為中間倉庫预愤，負(fù)責(zé)與消費(fèi)者打交道沟于，同時(shí)保證后續(xù)交付可靠性的角色，就是消息隊(duì)列來擔(dān)當(dāng)?shù)摹?3
那么如何設(shè)計(jì)一個(gè)完全可靠的消息系統(tǒng)呢植康？
（1）生產(chǎn)者將生產(chǎn)的消息保存在數(shù)據(jù)庫做持久化旷太；
（2）消息broker接收到消息后也做持久化存儲(chǔ)；
（3）消費(fèi)者請(qǐng)求消息后返回ack销睁，如果請(qǐng)求失敗則retry.
RPC系統(tǒng)
對(duì)業(yè)務(wù)透明供璧，提取公共服務(wù)。
Dubbo是一個(gè)典型的RPC分布式服務(wù)框架榄攀，致力于提供高性能和透明化的RPC遠(yuǎn)程服務(wù)調(diào)用方案嗜傅，是阿里巴巴SOA服務(wù)化治理方案的核心框架。
如何實(shí)現(xiàn)RPC的服務(wù)化呢檩赢？
（1）服務(wù)提供者在服務(wù)注冊(cè)中心注冊(cè)服務(wù)吕嘀，提供對(duì)外接口；
（2）服務(wù)使用方從服務(wù)注冊(cè)中心訂閱感興趣的服務(wù)贞瞒；
（3）當(dāng)服務(wù)有變動(dòng)時(shí)偶房，服務(wù)注冊(cè)中心可通知使用方；
（4）服務(wù)使用方使用從注冊(cè)中心得到的接口信息使用服務(wù)军浆。
Schedule
分布式任務(wù)調(diào)度
解決定時(shí)任務(wù)的單點(diǎn)棕洋，定時(shí)問題的集中監(jiān)控，集中管理等問題乒融。
原有的定時(shí)任務(wù)一般都是單點(diǎn)部署掰盘，可靠性不高，并且定時(shí)任務(wù)就像一個(gè)黑洞赞季，要監(jiān)控定時(shí)任務(wù)的狀態(tài)總是一遍遍的添加監(jiān)控愧捕，維護(hù)監(jiān)控。這些工作總是重復(fù)進(jìn)行申钩。
使用Schedule后次绘，處理任務(wù)的worker可以多臺(tái)部署，在任務(wù)調(diào)度執(zhí)行時(shí)只有一臺(tái)會(huì)參與執(zhí)行撒遣，其中一臺(tái)離線后Schedule會(huì)選擇其他worker執(zhí)行邮偎。并且可以通過Schedule提供的管理界面監(jiān)控任務(wù)執(zhí)行進(jìn)度，任務(wù)執(zhí)行過程中生成的日志义黎，可以指定任務(wù)執(zhí)行失敗后的恢復(fù)策略禾进，可以人工介入任務(wù)的執(zhí)行。
Config
配置中心
1轩缤、將配置和代碼相分離命迈，集中管理所有的配置贩绕。配置中心會(huì)根據(jù)不同的環(huán)境下發(fā)不同的配置，配合最新的發(fā)布系統(tǒng)(QDR)壶愤，我們可以實(shí)現(xiàn)打包一次部署到任意環(huán)境淑倾，不僅可以節(jié)約發(fā)布時(shí)間，更可以讓流程更順暢(經(jīng)過測(cè)試的war包部署到線上)征椒。
2娇哆、監(jiān)控配置文件的發(fā)布流程。 將配置文件的修改和發(fā)布透明化勃救；吸取我們之前在使用配置文件時(shí)的教訓(xùn)碍讨，將使用配置文件的最佳實(shí)踐融合到發(fā)布流程中。
3蒙秒、熱發(fā)布配置文件勃黍。 在配置中心后臺(tái)修改配置文件發(fā)布后應(yīng)用會(huì)拿到最新的變更。
4晕讲、生產(chǎn)環(huán)境灰度測(cè)試. 修改配置后可以手動(dòng)將改動(dòng)推送到生產(chǎn)環(huán)境某臺(tái)機(jī)器進(jìn)行線上測(cè)試. 待完全通過后再批量生效覆获。
5、失敗回滾機(jī)制. 當(dāng)配置文件解析失敗后會(huì)自動(dòng)回滾到上個(gè)版本. 保證生產(chǎn)環(huán)境穩(wěn)定運(yùn)行.
Tracer
分布式鏈路追蹤系統(tǒng)用于在龐大的分布式集群系統(tǒng)的調(diào)用關(guān)系復(fù)雜的情況下瓢省，快速定位問題弄息；
分布式鏈路跟蹤系統(tǒng)被廣為熟知源于Google Dapper論文，隨后Twitter開發(fā)了ZipKin勤婚，eBay開發(fā)了Centralized Activity Logging(CAL)摹量，淘寶開發(fā)了鷹眼(EagleEye)
ClientDB
分庫分表
二、互聯(lián)網(wǎng)高可用架構(gòu)馒胆，為什么要服務(wù)化缨称？
在服務(wù)化之前，互聯(lián)網(wǎng)的高可用架構(gòu)大致是這樣一個(gè)架構(gòu)：
（ 1 ）用戶端是瀏覽器 / APP 客戶端
（ 2 ）后端入口是高可用的 nginx 集群祝迂，用于做反向代理
（ 3 ）中間核心是高可用的 web-server 集群具钥， 研發(fā)工程師主要編碼工作就是在這一層
（ 4 ）后端存儲(chǔ)是高可用的 db 集群，數(shù)據(jù)存儲(chǔ)在這一層
更典型的液兽， web-server 層是通過 DAO/ORM 等技術(shù)來訪問數(shù)據(jù)庫的：
架構(gòu)痛點(diǎn)一：代碼到處拷貝
舉一個(gè)最常見的業(yè)務(wù)的例子 -> 用戶數(shù)據(jù)的訪問，絕大部分公司都有一個(gè)數(shù)據(jù)庫存儲(chǔ)用戶數(shù)據(jù)掌动，各個(gè)業(yè)務(wù)都有訪問用戶數(shù)據(jù)的需求：
在有用戶服務(wù)之前四啰， 各個(gè)業(yè)務(wù)線都是自己通過 DAO 寫 SQL 訪問 user 庫來存取用戶數(shù)據(jù)，這無形中就導(dǎo)致了代碼的拷貝 粗恢。
架構(gòu)痛點(diǎn)二：復(fù)雜性擴(kuò)散
隨著并發(fā)量的越來越高柑晒，用戶數(shù)據(jù)的訪問數(shù)據(jù)庫成了瓶頸，需要加入緩存來降低數(shù)據(jù)庫的讀壓力眷射，于是架構(gòu)中引入了緩存匙赞，由于沒有統(tǒng)一的服務(wù)層佛掖， 各個(gè)業(yè)務(wù)線都需要關(guān)注緩存的引入導(dǎo)致的復(fù)雜性。
對(duì)于用戶數(shù)據(jù)的寫請(qǐng)求，所有業(yè)務(wù)線都要升級(jí)代碼： （ 1 ）先淘汰 cache （ 2 ）再寫數(shù)據(jù)
對(duì)于用戶數(shù)據(jù)的讀請(qǐng)求坐榆，所有業(yè)務(wù)線也都要升級(jí)代碼： （ 1 ）先讀 cache 拴魄，命中則返回 （ 2 ）沒命中則讀數(shù)據(jù)庫 （ 3 ）再把數(shù)據(jù)放入 cache
這個(gè)復(fù)雜性是典型的“業(yè)務(wù)無關(guān)”的復(fù)雜性，業(yè)務(wù)方需要被迫升級(jí)席镀。
架構(gòu)痛點(diǎn)三：庫的復(fù)用與耦合
服務(wù)化并不是唯一的解決上述兩痛點(diǎn)的方法匹中，抽象出統(tǒng)一的 “ 庫 ” 是最先容易想到的解決：
（ 1 ）代碼拷貝
（ 2 ）復(fù)雜性擴(kuò)散
的方法。抽象出一個(gè) user.so 豪诲，負(fù)責(zé)整個(gè)用戶數(shù)據(jù)的存取顶捷，從而避免代碼的拷貝。至于復(fù)雜性屎篱，也只有 user.so 這一個(gè)地方需要關(guān)注了服赎。解決了舊的問題，會(huì)引入新的問題芳室， 庫的版本維護(hù)與業(yè)務(wù)線之間代碼的耦合 ：業(yè)務(wù)線 A 將 user.so 由版本 1 升級(jí)至版本 2 专肪，如果不兼容業(yè)務(wù)線 B 的代碼，會(huì)導(dǎo)致 B 業(yè)務(wù)出現(xiàn)問題堪侯；業(yè)務(wù)線 A 如果通知了業(yè)務(wù)線 B 升級(jí)嚎尤，則是的業(yè)務(wù)線 B 會(huì)無故做一些“自身業(yè)務(wù)無關(guān)”的升級(jí)，非常郁悶伍宦。當(dāng)然芽死，如果各個(gè)業(yè)務(wù)線都是拷貝了一份代碼則不存在這個(gè)問題。
架構(gòu)痛點(diǎn)四： SQL質(zhì)量得不到保障次洼，業(yè)務(wù)相互影響
業(yè)務(wù)線通過 DAO 訪問數(shù)據(jù)庫：
本質(zhì)上 SQL 語句還是各個(gè)業(yè)務(wù)線拼裝的关贵，資深的工程師寫出高質(zhì)量的 SQL 沒啥問題，經(jīng)驗(yàn)沒有這么豐富的工程師可能會(huì)寫出一些低效的 SQL 卖毁， 假如業(yè)務(wù)線 A 寫了一個(gè)全表掃描的 SQL 揖曾，導(dǎo)致數(shù)據(jù)庫的 CPU100% ，影響的不只是一個(gè)業(yè)務(wù)線亥啦，而是所有的業(yè)務(wù)線都會(huì)受影響 炭剪。
三、服務(wù)化解決了什么問題
為了解決上面的諸多問題翔脱，互聯(lián)網(wǎng)高可用分層架構(gòu)演進(jìn)的過程中奴拦，引入了“服務(wù)層”。
1届吁、調(diào)用方友好
有服務(wù)層之前：業(yè)務(wù)方訪問用戶數(shù)據(jù)错妖，需要通過 DAO 拼裝 SQL 訪問绿鸣；有服務(wù)層之后： 業(yè)務(wù)方通過 RPC 訪問用戶數(shù)據(jù)，就像調(diào)用一個(gè)本地函數(shù)一樣暂氯，非常友好方便潮模。
2、 提高復(fù)用性株旷，防止代碼拷貝
3再登、 專注，屏蔽底層復(fù)雜度
4沽损、SQL 質(zhì)量得到保障
5、提供有限接口循头，無限性能\
在服務(wù)化之前绵估，各業(yè)務(wù)線上游想怎么操縱數(shù)據(jù)庫都行，遇到了性能瓶頸卡骂，各業(yè)務(wù)線容易扯皮国裳，相互推諉；服務(wù)化之后全跨， 服務(wù)只提供有限的通用接口缝左，理論上服務(wù)集群能夠提供無限性能，性能出現(xiàn)瓶頸浓若，服務(wù)層一處集中優(yōu)化 渺杉。
