青龍系統架構演進過程中，從高可用，高效能，資料一致性，使用者體驗四個方面，積累了豐富的經驗，確保了青龍系統在發展過程贏得了公司內外的口碑。
每年「雙十一」都是網購狂歡節，假設當天哪個電商系統出現系統不可用，那幾乎是災難性的，不僅會導致使用者快速流失，而且，公司將承受重大損失，甚至在未來競爭中失敗。即使對於創業公司，在當前獲取使用者如此昂貴和競爭如此激烈的情況下，系統不可用的代價也是非常大的，會遭到使用者的拋棄而失敗。
青龍系統作為京東後台物流系統，系統高可用也同樣重要，因為，即使在平時，物流系統出現不可用的情況，會造成訂單時效履約失敗，極大影響使用者體驗，這也是無法接受的；同時，系統不可用也會導致數十萬員工無法正常工作，對於效率極大影響，公司損失也非常大。我們在研發過程中，對於系統高可用，也積累了豐富經驗，主要包括：合適的架構方案；大系統小做，服務拆分；併發控制，服務隔離；灰度發布；全方位監控報警；核心服務，平滑降級。
首先是選擇合適的架構方案。網際網路系統一般可以分為前端應用系統和後端資料庫系統，前端應用系統實施分布式集群部署技術上是比較成熟的，後端資料庫系統實現異地多活技術難度很大，目前也只有阿里，京東這樣的公司才真正實現。因此，對於大多數應用，前端應用雙機房集群部署，後端資料庫系統採取成熟的主備從的模式，也就是單個機房作為寫入，備庫在另外機房，可以快速進行切換，讀庫雙機房部署，是優選的方案。對於這個架構方案，存在跨機房寫延長的問題，可以根據場景利用非同步的方式進行解決，一般也是沒有問題的。對於青龍系統來講，也有些特別，利用分揀中心的本地伺服器和操作人員的裝置，實現離線生產，進一步提高可用性。
大系統小做，服務拆分，是網際網路應用的特點，也符合敏捷交付的理念。對於傳統軟體，如windows，office等，都要經過乙個漫長的需求，研發，測試，發布週期，在「唯快不破」的網際網路時代，這顯然是無法滿足業務要求的，即使最後上線，也可能因為週期太長而不再適用了。因此，對乙個網際網路服務，一般會首先完成最核心的功能，快速進行上線，不斷進行迭代，後續再進行輔助功能跟進。對於核心功能，隨著使用者數的增加，會不斷進行服務拆分，如何進行拆分，拆分到什麼樣的粒度，是不是微服務是解決問題的銀彈？這些都要根據實際的應用場景來評估，絕不是越細越好，而是要達到乙個優雅的平衡。
併發控制，服務隔離。併發控制，現在已經成為網際網路服務基本要求，在應用程式端和資料庫端，也都有成熟的方案，如果忽略，可能造成災難性的後果。對於重要的服務，還要進行隔離，例如同乙個服務，要提供給內部呼叫，公司級呼叫和公司外開放服務呼叫，開放服務呼叫者我們一般認為是不可靠的，甚至有可能是惡意的，如果不進行隔離，開放服務呼叫有可能使得服務資源佔滿，對內也無法提供服務。從技術上，可以是硬體級隔離，全部隔離，也可以是前端應用的隔離。
全方位監控報警，可以分為技術層面和業務層面，技術層面包括對cpu，記憶體，磁碟，網路等的監控，業務層面，包括對處理積壓量，正常的業務量等。做到全方位監控，才有可能在影響使用者之前，提前解決問題，提公升系統可用性。否則，等使用者發現問題，在很大的壓力下，技術團隊更難處理，導致系統不可用時間加長。
最後就是，核心服務，平滑降級。任何技術手段，都不可能保障100%可用，並且，即使能夠做到，其代價也是巨大，不經濟的，因此，對於核心服務來講，能夠平滑進行降級，提供基礎的服務，也是非常重要的。對於青龍系統來講，就利用分揀中心本地伺服器和操作人員的裝置，研發了離線生產系統，來應對集中服務萬一不可用的情況。
對應網際網路服務來說，高效能是必須的，使用者的響應一般都要求是秒級，而乙個使用者操作都包含多個服務呼叫，對應服務介面響應的要求都是毫秒級。對應青龍系統來講，支援物流操作人員有十萬餘人，每個操作提公升一秒，那麼就能節約三個人員，意義是非常大的。
資料服務，對於大型網際網路應用，已經變為非常核心，稱為系統的大腦也不為過。
我們一般需要考慮實時性和一致性，這兩個最重要的維度，當然，資料量也是乙個維度，一般我們認為是大資料的應用場景。
這樣，我們就能分為四個基本的場景：高實時性/高一致性，高實時性/低一致性，低實時性/高一致性，低實時性/低一致性。針對具體的業務，我們可以匹配到具體的資料場景，這樣，我們就能找到對應的解決方案。在這個過程中，客觀的進行業務分析非常重要，並不是，選擇高實時性/高一致性是最優方案，因為這個方案的實現成本是最昂貴的，可能是不經濟，也沒有必要的。
實時&強一致場景：這個在大資料技術成熟之前，是非常棘手的，但是，現在解決方案已經比較成熟了。典型應用是生產系統的實時監控，例如實時生產量，各個生產環節差異量等，其實是作為生產系統的一部分。利用當前主流的大資料處理架構是可以解決的，例如線上生產庫binlog實時讀取，kafaka進行資料傳輸，spark進行流式計算，es進行資料儲存等。如果利用傳統的etl抽取方案來解決，頻繁對生產資料庫進行抽取，並不是可行的方案，因為，這樣會極大的影響線上oltp系統的效能。還可以舉乙個生產系統實時監控案例，架構方案是應用系統完成寫資料庫的同時，把內容通過訊息傳送，後面的大資料處理系統接收訊息來進行處理，這個架構方案，對於實時性某種程度上可以保障，但是，也存在效率問題，但是，對於強一致性就非常不合適了，因為訊息系統如activemq等不僅無法保障訊息資料不能丟失，而且對應訊息順序也是無法保障，專案實施後，雖然採取了很多補救措施，也無法滿足強一致性需求，不得不重起爐灶。
實時&弱一致性場景：典型的應用場景是訊息通知，例如電商的全程跟蹤訊息，如果個別資料出現丟失，對於使用者的影響並不大，也是可以接受的，因此，可以採用更加廉價的解決方案，應用完成對應的動作後，將訊息發出即可，使用方訂閱對應的訊息，按照主鍵，如訂單號，儲存即可。
離線&強一致場景：這是典型的大資料分析場景，也就是眾多的離線報表模式。從技術上，傳統的etl抽取技術也能滿足要求，資料倉儲對應的技術也能夠解決。
離線&弱一致場景：對於抓取網際網路資料，日誌分析等進行統計系統，用於統計趨勢類的應用，可以歸為此類，這類應用主要是看能夠有足夠廉價的方案來解決，是不是可以巧妙的利用空閒的計算資源。這個在很多公司，利用晚上空閒的計算資源，來處理此類的需求。
以上討論的都是大資料應用，也就是從資料量大的應用場景。但是，對應現實中很多資料處理系統來講，例如很多b2b業務系統，或者傳統行業，其實是資料量並大，那麼採用更加廉價的oltp的方法，例如複製讀庫等，也是可以完成對應的工作的。
因此，架構設計應當針對具體應用場景的，滿足當前業務的發展需求，可以考慮兩年的需求，最合適的架構就是最好的，而不存在放之四海都是最好的架構設計。不分析清楚自己的應用場景，盲目照抄大公司的技術架構，顯然也是不合適的。當然，如果選擇的架構本身，不能滿足應用場景的需求，後續，不論進行多少補救，依然無法滿足需求，並且，架構會變得異常複雜，替換的成本也將是非常高昂，不得不慎重。
京東是非常重視使用者體驗的公司，老劉就明確指出任何人不能對使用者體驗提公升的意見說no。青龍系統在研發過程中，我們認為mvp原則和動態運營是非常重要的。
mvp原則，也就是敏捷開發中的迭代思路。對應乙個大的專案，按照傳統的瀑布模型，一般經歷設計，研發，測試到最後上線階段，這對於網際網路應用來說，很多情況下是不能接受的，因為業務需求變化太快，如果上線週期太長，也許上線後發現情況已經變化了，或者，上線後發現不能落地推廣。因此，對應乙個大專案，一般會進行迭代分解，最核心的需求，會優先開發，並完成上線，上線驗證後，繼續開發優先順序低的需求。
動態運營，其實也和mvp原則有很強的聯絡，也就是功能上線後，要真正運營起來，看具體資料，如果發現和設計不符合，那麼，就要進行調整，到符合使用者需求。這也是網際網路服務的使用者體驗，要優於傳統的軟體開發系統，傳統軟體開發基本上上線後就不在優化了，而對於網際網路服務來說，上線只是開始，只有將這個功能運營好，才叫好，並且，這個過程一直是持續的。
對於如何打造乙個高可用的網際網路系統，上面很多點大家都知道，包括高可用，高效能，資料一致性和使用者體驗，關鍵是如何落實和做到極致，就如大家都學習賈伯斯，但是，能夠真正把產品做到極致的還是鳳毛麟角。
有讚搜尋系統的架構演進
摘要 有讚搜尋平台是乙個面向公司內部各項搜尋應用以及部分 nosql 儲存應用的 paas 產品，幫助應用合理高效的支援檢索和多維過濾功能，有讚搜尋平台目前支援了大大小小一百多個檢索業務，服務於近百億資料。在為傳統的搜尋應用提供高階檢索和大資料互動能力的同時，有讚搜尋平台還需要為其他比如商品管理 訂...
演進式架構設計在敏捷開發中的使用
在敏捷開發過程中，我們還需要對系統架構進行設計嗎?事實上，martin fowler 在 is design dead?一文中已經給出了答案，那就是我們同樣不能忽略對系統架構的設計。與計畫性的設計 planned design 不同，我們需要演進式的設計 evolutionary design ib...
高併發 低 RT 的風控系統架構及技術架構的實現
由於風控系統具有隱秘性，本次分享不具體 業務，主要聚焦在技術架構上，近年來風控相關的技術及框架層出不窮，填補了很多功能上的空白，再加上使用者的資料關係越來越複雜且資料量龐大，催生出了很多現代化的需求，比如滑動時間視窗 自動識別風險及規則提煉等。風控的技術挑戰主要是低 rt 平均每個請求要在 100m...