之前開發了一個包括多端（PC端，移動端，微信端，API）的B2B系統，分享一下系統的架構設計演進。
技術選型
playframework
無狀態
全棧(Hibernate,Netty,Groovy,Cache)
Python運維支持，開發熱加載
AngularJS
對象操作
雙向綁定
模版
這樣的技術選型是基於低成本／小規模團隊快速上線應用的需要。
選擇playframework是它讓我們從開發到運維都能省去很多成本，對於開發人員只要掌握一定的語法就可以直接關注業務邏輯，不用所有的人都特別深入的學習框架。
自動編譯和重載：當編輯Java文件並保存後，刷新瀏覽器就能立即查看結果。使用playframework開發(生產還是需要重啟的)不需要手動編譯、部署以及重新啟動Web服務器等操作。
無狀態模型：playframework是真正的無共享框架，為REST而準備。它可以將同一個應用的多個實例分別部署在多臺服務器上，因而擴展性非常強。
高效的模板引擎：基於表達式語言Groovy的清晰模板引擎，提供了模板的繼承、導入以及標籤自定義等功能。
快速解決錯誤：當錯誤發生時，playframework(play1)會在瀏覽器中顯示出錯代碼塊並提示問題發生的確切位置。
Full Stack:提供創建Web應用所需的全部功能，集成了Hibernate、OpenID、Memcached等第三方類庫。
純Java：playframework(play1)採用Java編寫代碼，可以方便地使用任何Java類庫，並且能夠非常好地和Eclipse、Netbeans等IDE集成，只需通過命令生成匹配的項目文件即可。
基於非阻塞的IO模型：允許創建基於長輪詢和WebSocket的主流Web應用。
有趣並且高效：省去了Java應用重啟的時間，提高了應用的開發效率。
選擇AngularJS是我們的應用更多的是後臺應用，在2014年輕量級可選擇的還只有knockout和angular，考慮到谷歌以及豐富的控件組件，mvvm的便捷實用我們選擇了它，現在它仍然在很好的發揮著作用，在前端開發人手不足時能讓後臺開發也能以面向對象的方式介入前臺開發，以便應用快速上線。
架構演進
我們並不是只用playframework提供的功能而已，在playframework的基礎上考慮整體的性能和擴展自定義開發等方面我們在playfamework上做了一些改造
強制使用上下文(控制邊界/業務隔離)
這個應用是個多租戶的應用，成本考慮不可能每個租戶一個庫，多個租戶在同一個庫中就存在租戶信息不隔離不安全的問題，我們在數據訪問層強制控制，不讓業務通過租戶字段訪問，而是公共部分統一插入租戶信息，這樣既讓業務無須關心租戶，當前用戶等業務周邊信息，也能讓類似租戶信息更安全。
實體緩存(提高效率)
為了提高系統操作效率，我們為每個實體訪問都設置了緩存，且無需業務干預和操作。能夠極大的提高數據庫的IO吞吐量。
引入元數據(規範操作,公共問題公共處理)
引入元數據可以讓業務有更多可複用，更多可配置及更聚焦業務本身。比如有些業務表需要有審計功能（需要知道某條記錄是誰修改，誰添加的），這個業務實體就可以實現審計接口，然後公共統一異步多線程處理審計問題，既能保證高效也能減少耦合。
回調機制(解耦/二開)
讓業務之間不再通過代碼相互調用，減少業務耦合。同時還可以更方便的讓二次開發通過這個機制參與進來。
playframework服務化(前後端分離/代碼複用/更豐富的API)
我們現在並沒有讓playframework來直接渲染界面，而是將playframework服務化，即它只提供後臺多終端服務，前端通過Node.js或PHP來展現，前後端分離，更易維護，也讓後端能發揮更大的作用。同時後端還可以隨時被更高效的框架或者語言替代（比如scala,go)。
Swagger:API量化(測試深入參與後端服務接口測試)
前後臺通過標準API文檔交互，同時第三方開發者也能有標準規範的開發文檔。而且業務接口變更或者新增，文檔能夠即時的更新，而不用手工操作！
大量使用多線程編程來提升系統運行效率
大量的異步多線程操作來保證系統運行效率。
同時我們使用阿里雲的OSS來做靜態資源(JS/CSS的存儲),使用七牛雲存儲來存儲站點的大量圖片和附件信息。
解決前端頁面加載效率因地區而異
節省帶寬資源
專注業務處理
為集群服務鋪路
在運維上我們做了一些優化提升
全站HTTPS
避免單點積壓
提高處理效率（相對部分HTTPS)
提升系統安全性
負載均衡
提升系統穩定性
提升訪問性能
分佈式memcached服務
避免單點雪崩效應
單實體強制緩存化(有效利用緩存分擔數據庫壓力)
ELK
提供集群部署下快速分析解決問題的入口和渠道
Swagger-API文檔
方便前後臺分離協同開發及第三方開發者社區規範開發
原文出處：xcoder/me