京東咚咚架構(gòu)演進(jìn)
咚咚是什么？咚咚之于京東相當(dāng)于旺旺之于淘寶，它們都是服務(wù)于買家和賣家的溝通。 自從京東開始為第三方賣家提供入駐平臺(tái)服務(wù)后，咚咚也就隨之誕生了。 我們首先看看它誕生之初是什么樣的。
1.0 誕生（2010 - 2011)
為了業(yè)務(wù)的快速上線，1.0 版本的技術(shù)架構(gòu)實(shí)現(xiàn)是非常直接且簡(jiǎn)單粗暴的。 如何簡(jiǎn)單粗暴法？請(qǐng)看架構(gòu)圖，如下。
1.0 的功能十分簡(jiǎn)單，實(shí)現(xiàn)了一個(gè) IM 的基本功能，接入、互通消息和狀態(tài)。 另外還有客服功能，就是顧客接入咨詢時(shí)的客服分配，按輪詢方式把顧客分配給在線的客服接待。 用開源 Mina 框架實(shí)現(xiàn)了 TCP 的長(zhǎng)連接接入，用 Tomcat Comet 機(jī)制實(shí)現(xiàn)了 HTTP 的長(zhǎng)輪詢服務(wù)。 而消息投遞的實(shí)現(xiàn)是一端發(fā)送的消息臨時(shí)存放在 redis 中，另一端拉取的生產(chǎn)消費(fèi)模型。
這個(gè)模型的做法導(dǎo)致需要以一種高頻率的方式來(lái)輪詢 Redis 遍歷屬于自己連接的關(guān)聯(lián)會(huì)話消息。 這個(gè)模型很簡(jiǎn)單，簡(jiǎn)單包括多個(gè)層面的意思：理解起來(lái)簡(jiǎn)單；開發(fā)起來(lái)簡(jiǎn)單；部署起來(lái)也簡(jiǎn)單。 只需要一個(gè) Tomcat 應(yīng)用依賴一個(gè)共享的 Redis，簡(jiǎn)單的實(shí)現(xiàn)核心業(yè)務(wù)功能，并支持業(yè)務(wù)快速上線。
但這個(gè)簡(jiǎn)單的模型也有些嚴(yán)重的缺陷，主要是效率和擴(kuò)展問題。 輪詢的頻率間隔大小基本決定了消息的延時(shí)，輪詢?cè)娇煅訒r(shí)越低，但輪詢?cè)娇煜囊苍礁摺?這個(gè)模型實(shí)際上是一個(gè)高功耗低效能的模型，因?yàn)椴换钴S的連接在那做高頻率的無(wú)意義輪詢。 高頻有多高呢，基本在 100 ms 以內(nèi)，你不能讓輪詢太慢，比如超過 2 秒輪一次，人就會(huì)在聊天過程中感受到明顯的會(huì)話延遲。 隨著在線人數(shù)增加，輪詢的耗時(shí)也線性增長(zhǎng)，因此這個(gè)模型導(dǎo)致了擴(kuò)展能力和承載能力都不好，一定會(huì)隨著在線人數(shù)的增長(zhǎng)碰到性能瓶頸。
1.0 的時(shí)代背景正是京東技術(shù)平臺(tái)從 .NET 向 JAVA 轉(zhuǎn)型的年代，我也正是在這期間加入京東并參與了京東主站技術(shù)轉(zhuǎn)型架構(gòu)升級(jí)的過程。 之后開始接手了京東咚咚，并持續(xù)完善這個(gè)產(chǎn)品，進(jìn)行了三次技術(shù)架構(gòu)演進(jìn)。
2.0 成長(zhǎng)（2012）
我們剛接手時(shí) 1.0 已在線上運(yùn)行并支持京東 POP（開放平臺(tái)）業(yè)務(wù)，之后京東打算組建自營(yíng)在線客服團(tuán)隊(duì)并落地在成都。 不管是自營(yíng)還是 POP 客服咨詢業(yè)務(wù)當(dāng)時(shí)都起步不久，1.0 架構(gòu)中的性能和效率缺陷問題還沒有達(dá)到引爆的業(yè)務(wù)量級(jí)。 而自營(yíng)客服當(dāng)時(shí)還處于起步階段，客服人數(shù)不足，服務(wù)能力不夠，顧客咨詢量遠(yuǎn)遠(yuǎn)超過客服的服務(wù)能力。 超出服務(wù)能力的顧客咨詢，當(dāng)時(shí)我們的系統(tǒng)統(tǒng)一返回提示客服繁忙，請(qǐng)稍后咨詢。 這種狀況導(dǎo)致高峰期大量顧客無(wú)論怎么刷新請(qǐng)求，都很可能無(wú)法接入客服，體驗(yàn)很差。 所以 2.0 重點(diǎn)放在了業(yè)務(wù)功能體驗(yàn)的提升上，如下圖所示。
針對(duì)無(wú)法及時(shí)提供服務(wù)的顧客，可以排隊(duì)或者留言。 針對(duì)純文字溝通，提供了文件和圖片等更豐富的表達(dá)方式。 另外支持了客服轉(zhuǎn)接和快捷回復(fù)等方式來(lái)提升客服的接待效率。 總之，整個(gè) 2.0 就是圍繞提升客服效率和用戶體驗(yàn)。 而我們擔(dān)心的效率問題在 2.0 高速發(fā)展業(yè)務(wù)的時(shí)期還沒有出現(xiàn)，但業(yè)務(wù)量正在逐漸積累，我們知道它快要爆了。 到 2012 年末，度過雙十一后開始了 3.0 的一次重大架構(gòu)升級(jí)。
3.0 爆發(fā)（2013 - 2014）
經(jīng)歷了 2.0 時(shí)代一整年的業(yè)務(wù)高速發(fā)展，實(shí)際上代碼規(guī)模膨脹的很快。 與代碼一塊膨脹的還有團(tuán)隊(duì)，從最初的 4 個(gè)人到近 30 人。 團(tuán)隊(duì)大了后，一個(gè)系統(tǒng)多人開發(fā)，開發(fā)人員層次不一，規(guī)范難統(tǒng)一，系統(tǒng)模塊耦合重，改動(dòng)溝通和依賴多，上線風(fēng)險(xiǎn)難以控制。 一個(gè)單獨(dú) tomcat 應(yīng)用多實(shí)例部署模型終于走到頭了，這個(gè)版本架構(gòu)升級(jí)的主題就是服務(wù)化。如果想學(xué)習(xí)Java工程化、高性能及分布式、深入淺出。微服務(wù)、Spring，MyBatis，Netty源碼分析的朋友可以加Java進(jìn)階群：726610841，群里有阿里大牛直播講解技術(shù)，以及Java大型互聯(lián)網(wǎng)技術(shù)的視頻免費(fèi)分享給大家。
服務(wù)化的第一個(gè)問題如何把一個(gè)大的應(yīng)用系統(tǒng)切分成子服務(wù)系統(tǒng)。 當(dāng)時(shí)的背景是京東的部署還在半自動(dòng)化年代，自動(dòng)部署系統(tǒng)剛起步，子服務(wù)系統(tǒng)若按業(yè)務(wù)劃分太細(xì)太多，部署工作量很大且難管理。 所以當(dāng)時(shí)我們不是按業(yè)務(wù)功能分區(qū)服務(wù)的，而是按業(yè)務(wù)重要性級(jí)別劃分了 0、1、2 三個(gè)級(jí)別不同的子業(yè)務(wù)服務(wù)系統(tǒng)。 另外就是獨(dú)立了一組接入服務(wù)，針對(duì)不同渠道和通信方式的接入端，見下圖。
更細(xì)化的應(yīng)用服務(wù)和架構(gòu)分層方式可見下圖。
這次大的架構(gòu)升級(jí)，主要考慮了三個(gè)方面：穩(wěn)定性、效率和容量。 做了下面這些事情：
1.業(yè)務(wù)分級(jí)、核心、非核心業(yè)務(wù)隔離
2.多機(jī)房部署，流量分流、容災(zāi)冗余、峰值應(yīng)對(duì)冗余
3.讀庫(kù)多源，失敗自動(dòng)轉(zhuǎn)移
4.寫庫(kù)主備，短暫有損服務(wù)容忍下的快速切換
5.外部接口，失敗轉(zhuǎn)移或快速斷路
6.Redis 主備，失敗轉(zhuǎn)移
7.大表遷移，MongoDB 取代 MySQL 存儲(chǔ)消息記錄
8.改進(jìn)消息投遞模型
前 6 條基本屬于考慮系統(tǒng)穩(wěn)定性、可用性方面的改進(jìn)升級(jí)。 這一塊屬于陸續(xù)迭代完成的，承載很多失敗轉(zhuǎn)移的配置和控制功能在上面圖中是由管控中心提供的。 第 7 條主要是隨著業(yè)務(wù)量的上升，單日消息量越來(lái)越大后，使用了 MongoDB 來(lái)單獨(dú)存儲(chǔ)量最大的聊天記錄。 第 8 條是針對(duì) 1.0 版本消息輪詢效率低的改進(jìn)，改進(jìn)后的投遞方式如下圖所示：
不再是輪詢了，而是讓終端每次建立連接后注冊(cè)接入點(diǎn)位置，消息投遞前定位連接所在接入點(diǎn)位置再推送過去。 這樣投遞效率就是恒定的了，而且很容易擴(kuò)展，在線人數(shù)越多則連接數(shù)越多，只需要擴(kuò)展接入點(diǎn)即可。 其實(shí)，這個(gè)模型依然還有些小問題，主要出在離線消息的處理上，可以先思考下，我們最后再講。
3.0 經(jīng)過了兩年的迭代式升級(jí)，單純從業(yè)務(wù)量上來(lái)說還可以繼續(xù)支撐很長(zhǎng)時(shí)間的增長(zhǎng)。 但實(shí)際上到 2014 年底我們面對(duì)的不再是業(yè)務(wù)量的問題，而是業(yè)務(wù)模式的變化。 這直接導(dǎo)致了一個(gè)全新時(shí)代的到來(lái)。
4.0 涅槃（2015 至今 )
2014 年京東的組織架構(gòu)發(fā)生了很大變化，從一個(gè)公司變成了一個(gè)集團(tuán)，下設(shè)多個(gè)子公司。 原來(lái)的商城成為了其中一個(gè)子公司，新成立的子公司包括京東金融、京東智能、京東到家、拍拍、海外事業(yè)部等。 各自業(yè)務(wù)范圍不同，業(yè)務(wù)模式也不同，但不管什么業(yè)務(wù)總是需要客服服務(wù)。 如何復(fù)用原來(lái)為商城量身訂做的咚咚客服系統(tǒng)并支持其他子公司業(yè)務(wù)快速接入成為我們新的課題。
最早要求接入的是拍拍網(wǎng)，它是從騰訊收購(gòu)的，所以是完全不同的賬戶和訂單交易體系。 由于時(shí)間緊迫，我們把為商城訂做的部分剝離，基于 3.0 架構(gòu)對(duì)接拍拍又單獨(dú)訂做了一套，并獨(dú)立部署，像下面這樣。
雖然在業(yè)務(wù)要求的時(shí)間點(diǎn)前完成了上線，但這樣做也帶來(lái)了明顯的問題：
1.復(fù)制工程，定制業(yè)務(wù)開發(fā)，多套源碼維護(hù)成本高
2.獨(dú)立部署，至少雙機(jī)房主備外加一個(gè)灰度集群，資源浪費(fèi)大
以前我們都是面向業(yè)務(wù)去架構(gòu)系統(tǒng)，如今新的業(yè)務(wù)變化形勢(shì)下我們開始考慮面向平臺(tái)去架構(gòu)，在統(tǒng)一平臺(tái)上跑多套業(yè)務(wù)，統(tǒng)一源碼，統(tǒng)一部署，統(tǒng)一維護(hù)。 把業(yè)務(wù)服務(wù)繼續(xù)拆分，剝離出最基礎(chǔ)的 IM 服務(wù)，IM 通用服務(wù)，客服通用服務(wù)，而針對(duì)不同的業(yè)務(wù)特殊需求做最小化的定制服務(wù)開發(fā)。 部署方式則以平臺(tái)形式部署，不同的業(yè)務(wù)方的服務(wù)跑在同一個(gè)平臺(tái)上，但數(shù)據(jù)互相隔離。 服務(wù)繼續(xù)被拆分的更微粒化，形成了一組服務(wù)矩陣（見下圖）。
而部署方式，只需要在雙機(jī)房建立兩套對(duì)等集群，并另外建一個(gè)較小的灰度發(fā)布集群即可，所有不同業(yè)務(wù)都運(yùn)行在統(tǒng)一平臺(tái)集群上。
更細(xì)粒度的服務(wù)意味著每個(gè)服務(wù)的開發(fā)更簡(jiǎn)單，代碼量更小，依賴更少，隔離穩(wěn)定性更高。 但更細(xì)粒度的服務(wù)也意味著更繁瑣的運(yùn)維監(jiān)控管理，直到今年公司內(nèi)部彈性私有云、緩存云、消息隊(duì)列、部署、監(jiān)控、日志等基礎(chǔ)系統(tǒng)日趨完善， 使得實(shí)施這類細(xì)粒度劃分的微服務(wù)架構(gòu)成為可能，運(yùn)維成本可控。 而從當(dāng)初 1.0 的 1 種應(yīng)用進(jìn)程，到 3.0 的 6、7 種應(yīng)用進(jìn)程，再到 4.0 的 50+ 更細(xì)粒度的不同種應(yīng)用進(jìn)程。 每種進(jìn)程再根據(jù)承載業(yè)務(wù)流量不同分配不同的實(shí)例數(shù)，真正的實(shí)例進(jìn)程數(shù)會(huì)過千。 為了更好的監(jiān)控和管理這些進(jìn)程，為此專門定制了一套面向服務(wù)的運(yùn)維管理系統(tǒng)。
統(tǒng)一服務(wù)運(yùn)維提供了實(shí)用的內(nèi)部工具和庫(kù)來(lái)幫助開發(fā)更健壯的微服務(wù)。 包括中心配置管理，流量埋點(diǎn)監(jiān)控，數(shù)據(jù)庫(kù)和緩存訪問，運(yùn)行時(shí)隔離，如下圖所示是一個(gè)運(yùn)行隔離。
細(xì)粒度的微服務(wù)做到了進(jìn)程間隔離，嚴(yán)格的開發(fā)規(guī)范和工具庫(kù)幫助實(shí)現(xiàn)了異步消息和異步 HTTP 來(lái)避免多個(gè)跨進(jìn)程的同步長(zhǎng)調(diào)用鏈。 進(jìn)程內(nèi)部通過切面方式引入了服務(wù)增強(qiáng)容器 Armor 來(lái)隔離線程， 并支持進(jìn)程內(nèi)的單獨(dú)業(yè)務(wù)降級(jí)和同步轉(zhuǎn)異步化執(zhí)行。而所有這些工具和庫(kù)服務(wù)都是為了兩個(gè)目標(biāo)：
1.讓服務(wù)進(jìn)程運(yùn)行時(shí)狀態(tài)可見
2.讓服務(wù)進(jìn)程運(yùn)行時(shí)狀態(tài)可被管理和改變
最后我們回到前文留下的一個(gè)懸念，就是關(guān)于消息投遞模型的缺陷。 一開始我們?cè)诮尤雽訖z測(cè)到終端連接斷開后，消息無(wú)法投遞，再將消息緩存下來(lái)，等終端重連接上來(lái)再拉取離線消息。 這個(gè)模型在移動(dòng)時(shí)代表現(xiàn)的很不好，因?yàn)橐苿?dòng)網(wǎng)絡(luò)的不穩(wěn)定性，導(dǎo)致經(jīng)常斷鏈后重連。 而準(zhǔn)確的檢測(cè)網(wǎng)絡(luò)連接斷開是依賴一個(gè)網(wǎng)絡(luò)超時(shí)的，導(dǎo)致檢測(cè)可能不準(zhǔn)確，引發(fā)消息假投遞成功。 新的模型如下圖所示，它不再依賴準(zhǔn)確的網(wǎng)絡(luò)連接檢測(cè)，投遞前待確認(rèn)消息 id 被緩存，而消息體被持久存儲(chǔ)。 等到終端接收確認(rèn)返回后，該消息才算投妥，未確認(rèn)的消息 id 再重新登陸后或重連接后作為離線消息推送。 這個(gè)模型不會(huì)產(chǎn)生消息假投妥導(dǎo)致的丟失，但可能導(dǎo)致消息重復(fù)，只需由客戶終端按消息 id 去重即可。
京東咚咚誕生之初正是京東技術(shù)轉(zhuǎn)型到 Java 之時(shí)，經(jīng)歷這些年的發(fā)展，取得了很大的進(jìn)步。 從草根走向?qū)I(yè)，從弱小走向規(guī)模，從分散走向統(tǒng)一，從雜亂走向規(guī)范。 本文主要重心放在了幾年來(lái)咚咚架構(gòu)演進(jìn)的過程，技術(shù)架構(gòu)單獨(dú)拿出來(lái)看我認(rèn)為沒有絕對(duì)的好與不好， 技術(shù)架構(gòu)總是要放在彼時(shí)的背景下來(lái)看，要考慮業(yè)務(wù)的時(shí)效價(jià)值、團(tuán)隊(duì)的規(guī)模和能力、環(huán)境基礎(chǔ)設(shè)施等等方面。 架構(gòu)演進(jìn)的生命周期適時(shí)匹配好業(yè)務(wù)的生命周期，才可能發(fā)揮最好的效果。
京東峰值系統(tǒng)設(shè)計(jì)
有別于社交網(wǎng)絡(luò)、搜索和游戲等網(wǎng)站，電商網(wǎng)站的用戶流量具有操作性強(qiáng)、隨時(shí)令變化等特點(diǎn)。在歐美國(guó)家，Black Friday和Cyber Monday標(biāo)志著節(jié)假日消費(fèi)的高峰。影響電商流量峰值的主要因素是搶購(gòu)、促銷和惡意攻擊，尤其是京東618店慶和雙11等大規(guī)模的促銷活動(dòng)。高流量、高并發(fā)情況下，如何保證整個(gè)系統(tǒng)的可靠性和穩(wěn)定性，是眾多電商企業(yè)研發(fā)團(tuán)隊(duì)都在思考的問題。
京東電商系統(tǒng)的設(shè)計(jì)是圍繞系統(tǒng)穩(wěn)定性、可靠性、高并發(fā)和可擴(kuò)展性為核心開展的。如何在峰值來(lái)臨時(shí)，保證用戶有平滑流暢的體驗(yàn)，且系統(tǒng)不會(huì)出現(xiàn)異常呢？我們先來(lái)看看京東系統(tǒng)的一些特點(diǎn)（圖1）。
圖1 系統(tǒng)架構(gòu)龐大復(fù)雜
京東的業(yè)務(wù)種類繁多，涉及SKU幾千萬(wàn)種，這使得系統(tǒng)龐大，外部需要對(duì)接供應(yīng)商、消費(fèi)者和第三方商家三大板塊。內(nèi)部系統(tǒng)包括了商品供應(yīng)鏈中除商品設(shè)計(jì)和生產(chǎn)外的幾乎所有環(huán)節(jié)，包括登錄、交易、后臺(tái)、供應(yīng)鏈、倉(cāng)配、客服等。所有這些涉及大小系統(tǒng)幾千個(gè)，造就了一個(gè)極其復(fù)雜龐大的體系。除此之外，京東系統(tǒng)交互強(qiáng)，各個(gè)功能模塊之間關(guān)聯(lián)性強(qiáng)，牽一發(fā)而動(dòng)全身，做任何修改都需要慎之又慎。因此，一切優(yōu)化方案都以保持系統(tǒng)穩(wěn)定為前提。
為了在復(fù)雜的系統(tǒng)基礎(chǔ)之上，盡量緩解峰值帶來(lái)的壓力，京東峰值系統(tǒng)的設(shè)計(jì)主要從性能提升、流量控制、災(zāi)備降級(jí)、壓測(cè)預(yù)案四個(gè)角度來(lái)進(jìn)行。
性能提升
切分業(yè)務(wù)系統(tǒng)
我們先將整個(gè)業(yè)務(wù)體系拆分為幾個(gè)相對(duì)獨(dú)立的子系統(tǒng)如SSO、交易平臺(tái)、POP平臺(tái)、訂單下傳系統(tǒng)、WMS和倉(cāng)儲(chǔ)配送（圖2）。每個(gè)子系統(tǒng)又可細(xì)分為若干部分，逐級(jí)簡(jiǎn)化，直至可操作可優(yōu)化的層級(jí)。例如，交易平臺(tái)包括價(jià)格、購(gòu)物車、結(jié)算、支付和訂單中心等；網(wǎng)站系統(tǒng)包括首頁(yè)、登錄、列表頻道、單品和搜索等。接下來(lái)，針對(duì)每個(gè)功能模塊的關(guān)鍵部分進(jìn)行切分，有針對(duì)性地做性能優(yōu)化。
圖2 業(yè)務(wù)切分方案
例如，交易的秒殺系統(tǒng)，原來(lái)是根植于普通交易系統(tǒng)之內(nèi)的，缺點(diǎn)非常明顯。當(dāng)流量突然增大時(shí)，不僅會(huì)導(dǎo)致秒殺系統(tǒng)反應(yīng)遲鈍，而且會(huì)影響普通交易系統(tǒng)的正常運(yùn)作。于是我們將其與其他業(yè)務(wù)系統(tǒng)物理分開，成為相對(duì)獨(dú)立的子系統(tǒng)。并且針對(duì)秒殺的特性，減少對(duì)后臺(tái)存儲(chǔ)的依賴。同時(shí)優(yōu)化中間層存儲(chǔ)機(jī)制，使得相對(duì)熱點(diǎn)分散部署。甚至支持單一SKU多點(diǎn)部署，從而大大提升了秒殺系統(tǒng)的吞吐量和可靠性。
分布式
分布式的交易系統(tǒng)是電商的未來(lái)。分布式系統(tǒng)解決兩大難題：提高用戶體驗(yàn)和增強(qiáng)容錯(cuò)能力。由于分布式系統(tǒng)設(shè)計(jì)時(shí)就會(huì)留有相當(dāng)?shù)牧髁吭鲩L(zhǎng)空間，所以當(dāng)一處數(shù)據(jù)中心飽和時(shí)，可以將其余的流量切入其他相對(duì)寬松的數(shù)據(jù)中心去，從而達(dá)到互為備份、互相支持的目的。與此同時(shí)，由于為提供用戶就近服務(wù)，所以減少了網(wǎng)絡(luò)延時(shí)，頁(yè)面反應(yīng)速度加快了。舉一個(gè)例子，google搜索是全球服務(wù)，歐亞美各地都有不同的IP提供服務(wù)。當(dāng)其中的某一個(gè)IP出現(xiàn)故障時(shí)，Google能夠從容地將其服務(wù)切換至最近的IP，繼續(xù)搜索服務(wù)。對(duì)于電商來(lái)說，情況更復(fù)雜一些，需要同步的數(shù)據(jù)要求更精確，數(shù)據(jù)量較大，對(duì)延時(shí)的容忍度更低，建設(shè)周期也就更長(zhǎng)。京東正在此方面著力改進(jìn)，從只讀的系統(tǒng)入手，一步一步實(shí)現(xiàn)系統(tǒng)的分布式。
API服務(wù)化
在各個(gè)系統(tǒng)中，總是有很多相同的組件。前端的負(fù)載均衡自不必說，中間件的處理就是非常典型的例子。如何高效統(tǒng)一地管理這些組件，API服務(wù)化是我們的答案。最好由一個(gè)訓(xùn)練有素的團(tuán)隊(duì)集中管理這些組件并對(duì)外提供接口服務(wù)，將軟件的使用復(fù)雜性隱藏起來(lái)，調(diào)用的是簡(jiǎn)單利索的API。讓專業(yè)人員去處理復(fù)雜邏輯，確保系統(tǒng)的可用性和擴(kuò)展性，既能大大降低出錯(cuò)概率，又能實(shí)現(xiàn)規(guī)模效益。
Redis是我們常用的緩存組件。 過去都是由各個(gè)業(yè)務(wù)實(shí)現(xiàn)團(tuán)隊(duì)進(jìn)行分別維護(hù)，專業(yè)性不強(qiáng)，使用多有不當(dāng)之處。后來(lái)我們進(jìn)行了集中管理，統(tǒng)一定制開發(fā)新功能和升級(jí)，并通過API服務(wù)化提供給各級(jí)用戶。這樣不僅豐富了應(yīng)用場(chǎng)景，還提升了性能和可靠性。
架構(gòu)，代碼優(yōu)化
一個(gè)合理的電商系統(tǒng)架構(gòu)是與一家公司的研發(fā)水平和技術(shù)管理水平密不可分的，這直接決定了可支撐峰值流量的多少和未來(lái)能達(dá)到的高度。選取適合自身發(fā)展的框架，既能充分發(fā)揮其效能，又可節(jié)約資源。代碼優(yōu)化也能提高效能，例如對(duì)于SQL語(yǔ)句的優(yōu)化，能更好地利用索引；Java/C++邏輯的優(yōu)化，減少了不必要的循環(huán)和復(fù)雜的操作；算法優(yōu)化，使之更高效；功能實(shí)現(xiàn)邏輯的優(yōu)化，變得更簡(jiǎn)潔和清晰；等等。但代碼優(yōu)化終究不能沖破極限， 難以追求極致，適可為止為宜。
系統(tǒng)虛擬彈性化
當(dāng)磁盤I/O不是瓶頸時(shí)，解決系統(tǒng)水平擴(kuò)展就會(huì)變得容易許多。可以通過ZooKeeper或類ZooKeeper將軟件棧有機(jī)地串聯(lián)起來(lái)，并配以有效的性能監(jiān)管。當(dāng)事務(wù)處理成為瓶頸時(shí)，利用當(dāng)今流行的虛擬化技術(shù)（如LXC或VM）可以在沒有人為干預(yù)的狀況下自動(dòng)進(jìn)行彈性擴(kuò)展。
