我想這兩天大家或多或少有在看李克強總理的政府工作報告，我也在電視旁愣著算是看完了全程，看完有個感受想反饋，要是總理的報告能和PPT搭配著講就更好了：）政府工作報告裡大篇幅回顧了2015年的工作，當時恰好在策劃聊聊架構下周的內容，突然靈感一現，為何我們本期的內容不以去年的變化和趨勢為切入點，談談架構的優化了？於是乎，便和當當網的史海鋒老師策劃了本期內容。
歡迎關注聊聊架構微信號，獲取更多精彩架構內容，下周我們將會發布《架構漫談》系列文章的電子書，敬請期待！
隨著移動互聯網的進一步普及，網上消費購物比例不斷提高，電商網站的系統規模隨業務快速增長，承載每天數以萬計的交易已經是主流電商網站的常態。
幾年前618、雙十一、雙十二標志著電商進入促銷常態化和大規模活動化階段，前兩年則是主打無線APP購物，那麼2015年，電商行業在業務模式上呈現出了哪些特征？我覺得可以簡單總結為4點。
渠道拓展
移動互聯網時代，流量入口愈加分散，催生出諸多導購引流的APP，電商公司需要具備對接多種渠道的能力，還要結合技術趨勢，開通微信公眾號，甚至是入駐其他零售平台、分銷平台，打造更多的垂直頻道，充分吸引流量。
實時交互
隨著大數據實時計算技術的成熟，當用戶在線時，根據用戶畫像和行為進行實時交互，結合業務活動提供精准的個性化即時服務，不浪費每一毫秒，提升客戶體驗，提高客戶粘性。
功能聚合
在每一個用戶打開的界面提供盡可能多的功能和信息，典型的是單品頁，現在堆滿了各種鏈接，顯示能夠使用哪些禮券、有哪些種促銷和服務，甚至商品副標題也會嵌入活動鏈接。竭盡所能利用流量，提高轉化。
精細運營
營銷越來越復雜，對運營的要求相應提高，運營人員必須了解每一個操作之後的效果是否符合預期，摸索對於不同的季節、地區、時段、客戶群體、商品品類最有效的營銷手段。
架構優化實踐
在這樣的背景下，當當網通過以下幾個方面來適應變化，並推進架構優化。
第一，對技術部組織架構進行調整。
將原來的職能化組織中的產品、研發和測試部門按照產品線進行整合，轉型為Unit化，以加強同一產品線不同職能團隊之間的配合協作，溝通更高效，團隊更為聚焦。
這樣的組織結構更易於應用敏捷，與實施敏捷的前提同理，產品線拆分建立在系統架構解耦基礎之上，在這一點上，系統架構與組織架構異曲同工且相輔相成。解耦越充分，系統邊界越清晰，模塊越小，越適合敏捷團隊，能夠快速響應業務需求。
業務相近的產品線組成一個產品研發部，這樣多數的小型需求在部門內就可以解決，面對緊急項目還可以靈活使用人力資源，並為員工創造接觸更多類型業務需求的機會。
第二，系統分層依賴。
隨著業務邏輯越來越復雜，系統越來越多，相互依賴也越來越多。比如我的當當中就聚合了安全中心、用戶、賬戶、訂單、收藏夾、推薦等多維度的信息，需要調用多個系統服務。經過討論，決定將用戶交互層面的前端頁面與原有的後端系統拆分，並入前端的產品線，以便為用戶提供更好的服務。
而後端系統之間的依賴關系也需要更為精細的分層定義，對於促銷系統，需要會員系統、訂單系統、價格系統提供基礎數據；對於運費系統需要商品信息和配貨數據，而在精准定位銷售區域的前提下，庫存只是配貨的基礎數據，配貨系統負責判斷是否有貨，Promise則根據配貨結果計算預計送達時間。
調整系統之間的關系是很難的，牽一發而動全身，但重構是契機，2015年，對於電商的核心系統交易和促銷進行了重構，同時價格、配貨、運費等系統也進行了較大調整，從而使系統間依賴問題得到了明顯改善。
第三，服務化。
微服務為互聯網行業的服務化指明了方向，也堅定了我們進行服務拆分和解耦的決心。
原有的架構以系統為維度，服務歸屬於明確的系統，而系統的劃分一般以業務功能為聚合，隨著業務的發展，新的業務功能層出不窮，總會有一些打破原有的系統邊界，給架構提出難題。
服務化，不僅是指系統將能力通過服務對外提供，更重要的是服務本身就是承載業務功能的單元，如果有組合了多個邏輯難以歸入某系統的服務，不必糾結，作為獨立的業務模塊開發就是了，以服務為單元，系統架構更加扁平，簡單清晰。
微服務架構中，服務粒度會更小，服務治理的需求更加迫切，更需要技術手段解決，比如分布式服務框架，當當使用的是基於Dubbo二次研發的DubboX，以及結合ddframe實現的服務調用監控。
去年的容器技術爆發，為微服務架構實施提供了有力工具，當當內部也在部分系統使用了Docker。
微服務大勢所趨，秉承SOA理念，在服務治理中心的基礎上，將系統弱化，提供更多的基礎服務，提高了系統的復用性和靈活性。
第四，平台化。
平台化包括兩個維度，技術平台化和系統平台化。
技術平台化是指在技術層面建立統一的體系，包括根據行業特點進行技術選型，使用穩定可靠的技術組件。
當當從2012年開始將原有的.net平台向Java平台遷移，從封閉到開源，應用電商行業的主流技術棧，到2015年，基本完成了技術轉型，主要後端業務系統都轉移到Java平台。
經過數年的積累，2015年當當架構部研發了Java應用開發框架ddframe，目的是分離技術和業務，封裝技術細節，將應用開發人員的精力集中在業務開發上。
隨後再接再厲，當當架構部又推出了用來替代TBSchedule的分布式作業調度框架Elastic-Job。並將之開源，基於JDBC的分布式數據庫中間件Sharding-JDBC也在開發中。
統一的技術棧，能夠復用技術資源，持續積累整體的研發能力，為做精做專提供更好的基礎條件。
系統平台化是指搭建基礎平台，包括測試平台、分布式服務平台、自動化運維平台、監控平台、緩存集群、消息中