原文：讀書_w3c架構(gòu)師01通用設(shè)計(jì)與方法論
讀書_w3c架構(gòu)師
架構(gòu) 秒殺系統(tǒng)優(yōu)化思路
基本思路
（1）將請求盡量攔截在系統(tǒng)上游（不要讓鎖沖突落到數(shù)據(jù)庫上去）
（2）充分利用緩存，秒殺買票肾档，這是一個(gè)典型的讀多寫少的應(yīng)用場景，大部分請求是車次查詢
第一層眷射，客戶端怎么優(yōu)化（瀏覽器層睛蛛，APP層）
（a）產(chǎn)品層面，用戶點(diǎn)擊“查詢”或者“購票”后，按鈕置灰苞七，禁止用戶重復(fù)提交請求藐守；
（b）JS層面，限制用戶在x秒之內(nèi)只能提交一次請求蹂风；
第二層卢厂，站點(diǎn)層面的請求攔截
怎么攔截？怎么防止程序員寫for循環(huán)調(diào)用惠啄，有去重依據(jù)么慎恒？
這類業(yè)務(wù)都需要登錄，用uid即可撵渡。在站點(diǎn)層面融柬，對uid進(jìn)行請求計(jì)數(shù)和去重，
5s只透過一個(gè)請求趋距，其余的請求怎么辦粒氧？緩存，頁面緩存棚品，同一個(gè)uid靠欢，限制訪問頻度，做頁面緩存铜跑，x秒內(nèi)到達(dá)站點(diǎn)層的請求门怪，均返回同一頁面。
第三層 服務(wù)層來攔截（反正就是不要讓請求落到數(shù)據(jù)庫上去）
意義呢锅纺？沒錯(cuò)掷空，請求隊(duì)列！
對于寫請求囤锉，做請求隊(duì)列坦弟，每次只透有限的寫請求去數(shù)據(jù)層（下訂單，支付這樣的寫業(yè)務(wù)）
1w部手機(jī)官地，只透1w個(gè)下單請求去db
3k張火車票酿傍，只透3k個(gè)下單請求去db
當(dāng)然，還有業(yè)務(wù)規(guī)則上的一些優(yōu)化驱入〕喑矗回想12306所做的，分時(shí)分段售票亏较，原來統(tǒng)一10點(diǎn)賣票莺褒，現(xiàn)在8點(diǎn)，8點(diǎn)半雪情，9點(diǎn)遵岩，...每隔半個(gè)小時(shí)放出一批：將流量攤勻。
第四層 最后是數(shù)據(jù)庫層
閑庭信步巡通，單機(jī)也能扛得住尘执，
架構(gòu) 細(xì)聊分布式ID生成方法
【常見方法一：使用數(shù)據(jù)庫的 auto_increment 來生成全局唯一遞增ID】
優(yōu)點(diǎn)：
（1）簡單舍哄，使用數(shù)據(jù)庫已有的功能
（2）能夠保證唯一性
（3）能夠保證遞增性
缺點(diǎn)：
（1）可用性難以保證：數(shù)據(jù)庫常見架構(gòu)是一主多從+讀寫分離，生成自增ID是寫請求正卧，主庫掛了就玩不轉(zhuǎn)了
（2）擴(kuò)展性差蠢熄，性能有上限：因?yàn)閷懭胧菃吸c(diǎn)，數(shù)據(jù)庫主庫的寫性能決定ID的生成性能上限炉旷，并且難以擴(kuò)展
改進(jìn)方法：
（1）增加主庫签孔，避免寫入單點(diǎn)
（2）數(shù)據(jù)水平切分，保證各主庫生成的ID不重復(fù)
改進(jìn)后的架構(gòu)保證了可用性窘行，但缺點(diǎn)是：
（1）喪失了ID生成的“絕對遞增性”
（2）數(shù)據(jù)庫的寫壓力依然很大饥追，每次生成ID都要訪問數(shù)據(jù)庫
【常見方法二：單點(diǎn)批量ID生成服務(wù)】
https://atts.w3cschool.cn/attachments/image/20170428/1493370800458061.png
優(yōu)點(diǎn)：
（1）保證了ID生成的絕對遞增有序
（2）大大的降低了數(shù)據(jù)庫的壓力，ID生成可以做到每秒生成幾萬幾十萬個(gè)
缺點(diǎn)：
（1）服務(wù)仍然是單點(diǎn)
（2）如果服務(wù)掛了罐盔，服務(wù)重啟起來之后但绕，繼續(xù)生成ID可能會(huì)不連續(xù)，中間出現(xiàn)空洞
（3）雖然每秒可以生成幾萬幾十萬個(gè)ID惶看，但畢竟還是有性能上限捏顺，無法進(jìn)行水平擴(kuò)展
改進(jìn)方法：
單點(diǎn)服務(wù)的常用高可用優(yōu)化方案是“備用服務(wù)”，也叫“影子服務(wù)”
https://atts.w3cschool.cn/attachments/image/20170428/1493370919182595.png
【常見方法三：uuid】
優(yōu)點(diǎn)：
（1）本地生成ID纬黎，不需要進(jìn)行遠(yuǎn)程調(diào)用幅骄，時(shí)延低
（2）擴(kuò)展性好，基本可以認(rèn)為沒有性能上限
缺點(diǎn)：
（1）無法保證趨勢遞增
（2）uuid過長本今，往往用字符串表示拆座，作為主鍵建立索引查詢效率低
【常見方法四：取當(dāng)前毫秒數(shù)】
優(yōu)點(diǎn)：
（1）本地生成ID，不需要進(jìn)行遠(yuǎn)程調(diào)用冠息，時(shí)延低
（2）生成的ID趨勢遞增
（3）生成的ID是整數(shù)挪凑，建立索引后查詢效率高
缺點(diǎn)：
（1）如果并發(fā)量超過1000，會(huì)生成重復(fù)的ID
【常見方法五：類snowflake算法】
snowflake是twitter開源的分布式ID生成算法逛艰，其核心思想是：一個(gè)long型的ID躏碳，使用其中41bit作為毫秒數(shù)，10bit作為機(jī)器編號(hào)散怖，12bit作為毫秒內(nèi)序列號(hào)唐断。這個(gè)算法單機(jī)每秒內(nèi)理論上最多可以生成1000*(2^12)，也就是400W的ID杭抠，完全能滿足業(yè)務(wù)的需求。
借鑒snowflake的思想恳啥，結(jié)合各公司的業(yè)務(wù)邏輯和并發(fā)量偏灿，可以實(shí)現(xiàn)自己的分布式ID生成算法。
缺點(diǎn)：
（1）由于“沒有一個(gè)全局時(shí)鐘”钝的，每臺(tái)服務(wù)器分配的ID是絕對遞增的翁垂，但從全局看铆遭，生成的ID只是趨勢遞增的（有些服務(wù)器的時(shí)間早，有些服務(wù)器的時(shí)間晚）
最后一個(gè)容易忽略的問題：
生成的ID沿猜，例如message-id/ order-id/ tiezi-id枚荣，在數(shù)據(jù)量大時(shí)往往需要分庫分表，這些ID經(jīng)常作為取模分庫分表的依據(jù)啼肩，為了分庫分表后數(shù)據(jù)均勻橄妆，ID生成往往有“取模隨機(jī)性”的需求，所以我們通常把每秒內(nèi)的序列號(hào)放在ID的最末位祈坠，保證生成的ID是隨機(jī)的害碾。
又如果，我們在跨毫秒時(shí)赦拘，序列號(hào)總是歸0慌随，會(huì)使得序列號(hào)為0的ID比較多，導(dǎo)致生成的ID取模后不均勻躺同。解決方法是阁猜，序列號(hào)不是每次都?xì)w0，而是歸一個(gè)0到9的隨機(jī)數(shù)蹋艺，這個(gè)地方剃袍。
互聯(lián)網(wǎng)架構(gòu)設(shè)計(jì)的容量評估
【步驟一：評估總訪問量】
->詢問業(yè)務(wù)、產(chǎn)品车海、運(yùn)營
【步驟二：評估平均訪問量QPS】
->除以時(shí)間笛园，一天算4w秒
【步驟三：評估高峰QPS】
->根據(jù)業(yè)務(wù)曲線圖來
【步驟四：評估系統(tǒng)、單機(jī)極限QPS】
->壓測很重要
【步驟五：根據(jù)線上冗余度回答兩個(gè)問題】
-> 估計(jì)冗余度與線上冗余度差值
架構(gòu) 線程數(shù)設(shè)置
Worker線程在執(zhí)行的過程中侍芝，有一部計(jì)算時(shí)間需要占用CPU研铆，另一部分等待時(shí)間不需要占用CPU，通過量化分析州叠，例如打日志進(jìn)行統(tǒng)計(jì)棵红，可以統(tǒng)計(jì)出整個(gè)Worker線程執(zhí)行過程中這兩部分時(shí)間的比例，例如：
1）時(shí)間軸1咧栗，3逆甜，5，7【上圖中粉色時(shí)間軸】的計(jì)算執(zhí)行時(shí)間是100ms
2）時(shí)間軸2致板，4交煞，6【上圖中橙色時(shí)間軸】的等待時(shí)間也是100ms
得到的結(jié)果是，這個(gè)線程計(jì)算和等待的時(shí)間是1：1斟或，即有50%的時(shí)間在計(jì)算（占用CPU）素征，50%的時(shí)間在等待（不占用CPU）：
1）假設(shè)此時(shí)是單核，則設(shè)置為2個(gè)工作線程就可以把CPU充分利用起來，讓CPU跑到100%
2）假設(shè)此時(shí)是N核御毅，則設(shè)置為2N個(gè)工作現(xiàn)場就可以把CPU充分利用起來根欧，讓CPU跑到N*100%
結(jié)論：
N核服務(wù)器，通過執(zhí)行業(yè)務(wù)的單線程分析出本地計(jì)算時(shí)間為x端蛆，等待時(shí)間為y凤粗，則工作線程數(shù)（線程池線程數(shù)）設(shè)置為 N*(x+y)/x，能讓CPU的利用率最大化今豆。
經(jīng)驗(yàn)：
一般來說嫌拣，非CPU密集型的業(yè)務(wù)（加解密、壓縮解壓縮晚凿、搜索排序等業(yè)務(wù)是CPU密集型的業(yè)務(wù)）亭罪，瓶頸都在后端數(shù)據(jù)庫，本地CPU計(jì)算的時(shí)間很少歼秽，所以設(shè)置幾十或者幾百個(gè)工作線程也都是可能的应役。
單點(diǎn)系統(tǒng)架構(gòu)的可用性與性能優(yōu)化
（1）單點(diǎn)系統(tǒng)存在的問題：可用性問題，性能瓶頸問題
（2）shadow-master是一種常見的解決單點(diǎn)系統(tǒng)可用性問題的方案
（3）減少與單點(diǎn)的交互燥筷，是存在單點(diǎn)的系統(tǒng)優(yōu)化的核心方向箩祥，常見方法有批量寫，客戶端緩存
（4）水平擴(kuò)展也是提升單點(diǎn)系統(tǒng)性能的好方案
一分鐘了解負(fù)載均衡的一切
負(fù)載均衡（Load Balance）是分布式系統(tǒng)架構(gòu)設(shè)計(jì)中必須考慮的因素之一肆氓，它通常是指袍祖，將請求/數(shù)據(jù)【均勻】分?jǐn)偟蕉鄠€(gè)操作單元上執(zhí)行，負(fù)載均衡的關(guān)鍵在于【均勻】谢揪。
（1）【客戶端層】到【反向代理層】的負(fù)載均衡蕉陋，是通過“DNS輪詢”實(shí)現(xiàn)的
（2）【反向代理層】到【站點(diǎn)層】的負(fù)載均衡，是通過“nginx”實(shí)現(xiàn)的
1）請求輪詢：和DNS輪詢類似拨扶，請求依次路由到各個(gè)web-server
2）最少連接路由：哪個(gè)web-server的連接少凳鬓，路由到哪個(gè)web-server
3）ip哈希：按照訪問用戶的ip哈希值來路由web-server，只要用戶的ip分布是均勻的患民，請求理論上也是均勻的缩举，ip哈希均衡方法可以做到，同一個(gè)用戶的請求固定落到同一臺(tái)web-server上匹颤，此策略適合有狀態(tài)服務(wù)仅孩，例如session（58沈劍備注：可以這么做，但強(qiáng)烈不建議這么做印蓖，站點(diǎn)層無狀態(tài)是分布式架構(gòu)設(shè)計(jì)的基本原則之一辽慕，session最好放到數(shù)據(jù)層存儲(chǔ)）
（3）【站點(diǎn)層】到【服務(wù)層】的負(fù)載均衡，是通過“服務(wù)連接池”實(shí)現(xiàn)的
（4）【數(shù)據(jù)層】的負(fù)載均衡赦肃，要考慮“數(shù)據(jù)的均衡”與“請求的均衡”兩個(gè)點(diǎn)溅蛉，常見的方式有“按照范圍水平切分”與“hash水平切分”
數(shù)據(jù)的均衡是指：水平切分后的每個(gè)服務(wù)（db绞旅，cache），數(shù)據(jù)量是差不多的温艇。
請求的均衡是指：水平切分后的每個(gè)服務(wù)（db，cache）堕汞，請求量是差不多的勺爱。
一、按照range水平切分
（1）規(guī)則簡單讯检，service只需判斷一下uid范圍就能路由到對應(yīng)的存儲(chǔ)服務(wù)
（2）數(shù)據(jù)均衡性較好
（3）比較容易擴(kuò)展琐鲁，可以隨時(shí)加一個(gè)uid[2kw,3kw]的數(shù)據(jù)服務(wù)
不足是：
（1）請求的負(fù)載不一定均衡，一般來說人灼，新注冊的用戶會(huì)比老用戶更活躍围段，大range的服務(wù)請求壓力會(huì)更大
二、按照id哈希水平切分
（1）規(guī)則簡單投放，service只需對uid進(jìn)行hash能路由到對應(yīng)的存儲(chǔ)服務(wù)
（2）數(shù)據(jù)均衡性較好
（3）請求均勻性較好
不足是：
（1）不容易擴(kuò)展奈泪，擴(kuò)展一個(gè)數(shù)據(jù)服務(wù)，hash方法改變時(shí)候灸芳，可能需要進(jìn)行數(shù)據(jù)遷移
lvs為何不能完全替代DNS輪詢
稍微做一個(gè)簡要的總結(jié)：
1）接入層架構(gòu)要考慮的問題域?yàn)椋焊呖捎美晕ΑU(kuò)展性、反向代理+擴(kuò)展均衡
2）nginx烙样、keepalived冯遂、lvs、f5可以很好的解決高可用谒获、擴(kuò)展性蛤肌、反向代理+擴(kuò)展均衡的問題
3）水平擴(kuò)展scale out是解決擴(kuò)展性問題的根本方案，DNS輪詢是不能完全被nginx/lvs/f5所替代的
https://atts.w3cschool.cn/attachments/image/20170503/1493804046106429.jpg
如何實(shí)施異構(gòu)服務(wù)器的負(fù)載均衡及過載保護(hù)
回答：互聯(lián)網(wǎng)軟件架構(gòu)設(shè)計(jì)中所指的過載保護(hù)批狱，是指當(dāng)系統(tǒng)負(fù)載超過一個(gè)service的處理能力時(shí)裸准，如果service不進(jìn)行自我保護(hù)，可能導(dǎo)致對外呈現(xiàn)處理能力為0精耐，且不能自動(dòng)恢復(fù)的現(xiàn)象狼速。而service的過載保護(hù)，是指即使系統(tǒng)負(fù)載超過一個(gè)service的處理能力卦停，service讓能保證對外提供有損的穩(wěn)定服務(wù)向胡。
https://atts.w3cschool.cn/attachments/image/20170503/1493801190334699.jpg
圖示：有過載保護(hù)的負(fù)載與處理能力圖（不會(huì)掉底）
提問：如何進(jìn)行過載保護(hù)？
回答：最簡易的方式惊完，服務(wù)端設(shè)定一個(gè)負(fù)載閾值僵芹，超過這個(gè)閾值的請求壓過來，全部拋棄小槐。這個(gè)方式不是特別優(yōu)雅拇派。
https://atts.w3cschool.cn/attachments/image/20170503/1493801291486853.jpg
需要注意的是：要防止客戶端的過載保護(hù)引起service的雪崩荷辕，如果“整體負(fù)載”已經(jīng)超過了“service集群”的處理能力，怎么轉(zhuǎn)移請求也是處理不過來的件豌，還得通過拋棄請求來實(shí)施自我保護(hù)疮方。
總結(jié)
1）service的負(fù)載均衡、故障轉(zhuǎn)移茧彤、超時(shí)處理通常是RPC-client連接池層面來實(shí)施的
2）異構(gòu)服務(wù)器負(fù)載均衡骡显，最簡單的方式是靜態(tài)權(quán)重法，缺點(diǎn)是無法自適應(yīng)動(dòng)態(tài)調(diào)整
3）動(dòng)態(tài)權(quán)重法曾掂，可以動(dòng)態(tài)的根據(jù)service的處理能力來分配負(fù)載惫谤，需要有連接池層面的微小改動(dòng)
4）過載保護(hù)，是在負(fù)載過高時(shí)珠洗，service為了保護(hù)自己溜歪，保證一定處理能力的一種自救方法
5）動(dòng)態(tài)權(quán)重法，還可以用做service的過載保護(hù)
究竟啥才是互聯(lián)網(wǎng)架構(gòu)“高并發(fā)”
高并發(fā)相關(guān)常用的一些指標(biāo)有響應(yīng)時(shí)間（Response Time）许蓖，吞吐量（Throughput）蝴猪，每秒查詢率QPS（Query Per Second），并發(fā)用戶數(shù)等蛔糯。
響應(yīng)時(shí)間：系統(tǒng)對請求做出響應(yīng)的時(shí)間拯腮。例如系統(tǒng)處理一個(gè)HTTP請求需要200ms，這個(gè)200ms就是系統(tǒng)的響應(yīng)時(shí)間蚁飒。
吞吐量：單位時(shí)間內(nèi)處理的請求數(shù)量动壤。
QPS：每秒響應(yīng)請求數(shù)。在互聯(lián)網(wǎng)領(lǐng)域淮逻，這個(gè)指標(biāo)和吞吐量區(qū)分的沒有這么明顯琼懊。
并發(fā)用戶數(shù)：同時(shí)承載正常使用系統(tǒng)功能的用戶數(shù)量。例如一個(gè)即時(shí)通訊系統(tǒng)爬早，同時(shí)在線量一定程度上代表了系統(tǒng)的并發(fā)用戶數(shù)哼丈。
二、如何提升系統(tǒng)的并發(fā)能力
總結(jié)
高并發(fā)（High Concurrency）是互聯(lián)網(wǎng)分布式系統(tǒng)架構(gòu)設(shè)計(jì)中必須考慮的因素之一筛严，它通常是指醉旦，通過設(shè)計(jì)保證系統(tǒng)能夠同時(shí)并行處理很多請求。
提高系統(tǒng)并發(fā)能力的方式桨啃，方法論上主要有兩種：垂直擴(kuò)展（Scale Up）與水平擴(kuò)展（Scale Out）车胡。前者垂直擴(kuò)展可以通過提升單機(jī)硬件性能，或者提升單機(jī)架構(gòu)性能照瘾，來提高并發(fā)性匈棘，但單機(jī)性能總是有極限的，互聯(lián)網(wǎng)分布式架構(gòu)設(shè)計(jì)高并發(fā)終極解決方案還是后者：水平擴(kuò)展析命。
互聯(lián)網(wǎng)分層架構(gòu)中主卫，各層次水平擴(kuò)展的實(shí)踐又有所不同：
（1）反向代理層可以通過“DNS輪詢”的方式來進(jìn)行水平擴(kuò)展逃默；
（2）站點(diǎn)層可以通過nginx來進(jìn)行水平擴(kuò)展；
（3）服務(wù)層可以通過服務(wù)連接池來進(jìn)行水平擴(kuò)展簇搅；
（4）數(shù)據(jù)庫可以按照數(shù)據(jù)范圍完域，或者數(shù)據(jù)哈希的方式來進(jìn)行水平擴(kuò)展；
各層實(shí)施水平擴(kuò)展后瘩将，能夠通過增加服務(wù)器數(shù)量的方式來提升系統(tǒng)的性能筒主，做到理論上的性能無限。
究竟啥才是互聯(lián)網(wǎng)架構(gòu)“高可用”
總結(jié)
高可用HA（High Availability）是分布式系統(tǒng)架構(gòu)設(shè)計(jì)中必須考慮的因素之一鸟蟹，它通常是指，通過設(shè)計(jì)減少系統(tǒng)不能提供服務(wù)的時(shí)間使兔。
方法論上建钥，高可用是通過冗余+自動(dòng)故障轉(zhuǎn)移來實(shí)現(xiàn)的。
整個(gè)互聯(lián)網(wǎng)分層系統(tǒng)架構(gòu)的高可用虐沥，又是通過每一層的冗余+自動(dòng)故障轉(zhuǎn)移來綜合實(shí)現(xiàn)的熊经，具體的：
（1）【客戶端層】到【反向代理層】的高可用，是通過反向代理層的冗余實(shí)現(xiàn)的欲险，常見實(shí)踐是keepalived + virtual IP自動(dòng)故障轉(zhuǎn)移
（2）【反向代理層】到【站點(diǎn)層】的高可用镐依，是通過站點(diǎn)層的冗余實(shí)現(xiàn)的，常見實(shí)踐是nginx與web-server之間的存活性探測與自動(dòng)故障轉(zhuǎn)移
（3）【站點(diǎn)層】到【服務(wù)層】的高可用天试，是通過服務(wù)層的冗余實(shí)現(xiàn)的槐壳，常見實(shí)踐是通過service-connection-pool來保證自動(dòng)故障轉(zhuǎn)移
（4）【服務(wù)層】到【緩存層】的高可用，是通過緩存數(shù)據(jù)的冗余實(shí)現(xiàn)的喜每，常見實(shí)踐是緩存客戶端雙讀雙寫务唐，或者利用緩存集群的主從數(shù)據(jù)同步與sentinel保活與自動(dòng)故障轉(zhuǎn)移带兜；更多的業(yè)務(wù)場景枫笛，對緩存沒有高可用要求，可以使用緩存服務(wù)化來對調(diào)用方屏蔽底層復(fù)雜性
【服務(wù)層】到【緩存層】的高可用刑巧，是通過緩存數(shù)據(jù)的冗余來實(shí)現(xiàn)的。
緩存層的數(shù)據(jù)冗余又有幾種方式：第一種是利用客戶端的封裝无畔，service對cache進(jìn)行雙讀或者雙寫。
緩存層也可以通過支持主從同步的緩存集群來解決緩存層的高可用問題檩互。
以redis為例，redis天然支持主從同步闸昨，redis官方也有sentinel哨兵機(jī)制薄风，來做redis的存活性檢測。
自動(dòng)故障轉(zhuǎn)移：當(dāng)redis主掛了的時(shí)候遭赂，sentinel能夠探測到，會(huì)通知調(diào)用方訪問新的redis撇他，整個(gè)過程由sentinel和redis集群配合完成，對調(diào)用方是透明的狈蚤。
（5）【服務(wù)層】到【數(shù)據(jù)庫“讀”】的高可用，是通過讀庫的冗余實(shí)現(xiàn)的脆侮，常見實(shí)踐是通過db-connection-pool來保證自動(dòng)故障轉(zhuǎn)移
（6）【服務(wù)層】到【數(shù)據(jù)庫“寫”】的高可用，是通過寫庫的冗余實(shí)現(xiàn)的靖避，常見實(shí)踐是keepalived + virtual IP自動(dòng)故障轉(zhuǎn)移
100億數(shù)據(jù)1萬屬性數(shù)據(jù)架構(gòu)設(shè)計(jì)
架構(gòu)設(shè)計(jì)中常見“反向依賴”與解耦方案
總結(jié)
如何發(fā)現(xiàn)系統(tǒng)架構(gòu)中不合理的“反向依賴”設(shè)計(jì)？
回答：
（1）變動(dòng)方是A幻捏，配合方卻是BCDE
（2）需求方是A盆犁，改動(dòng)方確是BCDE
想想“換IP的是你，配合重啟的卻是我”篡九，此時(shí)往往架構(gòu)上可以進(jìn)行解耦優(yōu)化谐岁。
常見反向依賴及優(yōu)化方案？
（1）公共庫導(dǎo)致耦合
優(yōu)化一：如果公共庫是業(yè)務(wù)特性代碼榛臼，進(jìn)行公共庫垂直拆分
優(yōu)化二：如果公共庫是業(yè)務(wù)共性代碼翰铡，進(jìn)行服務(wù)化下沉抽象
（2）服務(wù)化不徹底導(dǎo)致耦合
特征：服務(wù)中包含大量“根據(jù)不同業(yè)務(wù)，執(zhí)行不同個(gè)性分支”的代碼
優(yōu)化方案：個(gè)性代碼放到業(yè)務(wù)層實(shí)現(xiàn)讽坏，將服務(wù)化更徹底更純粹
（3）notify的不合理實(shí)現(xiàn)導(dǎo)致的耦合
特征：調(diào)用方不關(guān)注執(zhí)行結(jié)果锭魔，以調(diào)用的方式去實(shí)現(xiàn)通知，新增訂閱者路呜，修改代碼的是發(fā)布者
優(yōu)化方案：通過MQ解耦
（4）配置中的ip導(dǎo)致上下游耦合
特征：多個(gè)上游需要修改配置重啟
優(yōu)化方案：使用內(nèi)網(wǎng)域名替代內(nèi)網(wǎng)ip迷捧，通過“修改DNS指向，統(tǒng)一切斷舊連接”的方式來上游無感切換
（5）下游擴(kuò)容導(dǎo)致上下游耦合
特性：多個(gè)上游需要修改配置重啟
典型數(shù)據(jù)庫架構(gòu)設(shè)計(jì)與實(shí)踐
總結(jié)
文章較長胀葱，希望至少記住這么幾點(diǎn)：
?業(yè)務(wù)初期用單庫
?讀壓力大漠秋，讀高可用，用分組
?數(shù)據(jù)量大抵屿，寫線性擴(kuò)容庆锦，用分片
?屬性短，訪問頻度高的屬性轧葛，垂直拆分到一起
