從傳統軟件公司跑出來已經一年有余，10多年的基礎平台研發和知識積累，讓轉型互聯網架構和開發感覺沒想象中的難，可能是逼格太低，亦或者公司的業務量還沒到爆發的時間。但是不管怎么說，能有一次從頭搭建互聯網應用的機會是可遇不可求的。多少人擠破了頭跳槽BAT，而偶卻不羡慕。不管結果如何，先結合公司業務和互聯網技術，把基礎架構和發展方向確定了、夯實了。
網上有很多文章都在講互聯網技術發展的幾個階段和對應的架構： LAMP、服務化、數據庫Sharding，只要是了解一點互聯網技術知識的通知都清楚。我來公司后，看到的系統結構是這樣的。看上去很厲害，有如此多的API站點和服務。但是細細了解卻發現：
1.服務層的9個服務，全部是一個一個windows service，並且全部是一行行代碼硬擼出來的，每個服務的代碼都不一樣，穩定性很差。不過還好，有個管理工具勉強進行狀態管理。
2.API層基本是每個功能一個站點，但是僅部署在2台服務器上，只能說很超前的結構。所有的API站點也是一個一個硬硬寫出來的。
3.API與后台服務是通過thrift通訊的。一開始采用的是短連接，各種不穩定和宕機，后來改成長連接，還是各種不穩定。后來改成了補償機制基本解決了。但是還是建議大家不要使用windows版本的thrift，各種坑。
4.UI層除App外，是asp.net MVC結構。在互聯網公司中，用asp.net MVC真的不多，但是考慮到技術人員的知識體系，我們義無反饋的扛起了這面大旗。
數據庫層面的結構更直接，Base、業務，兩個數據庫，base庫是基礎數據，通過發布訂閱同步到業務庫中。業務量不大。
通過上面的情況，可以看到設計者的初衷是好的，本想通過一個松散的部署結構來支撐后續業務的水平擴展，但是缺乏統一的框架支持，存在太多太多的問題。先不說結構是否合理，如此多的部署節點，制作補丁、更新補丁就需要消耗巨大的工作量，一個功能的上線非常非常復雜，而且極其容易出現發布問題。
另外，整個集群有幾十台機器，每天夜里睡着覺，突然會被電話吵醒：XXX充不上電了。尼瑪，缺少最基本、最重要的監控。所有系統、集群、程序的運行全部是黑盒子，關鍵是出問題了你還不知道，要等到客戶給你反饋。太崩潰了，經歷過幾個晚上，簡直要瘋掉的節奏。那段時間有太多的問候。。。
經過一段時間的了解和總結，最終確定系統的架構如下：
1.UI層繼續延續現有的結構，后續逐漸向前后端分離發展，逐漸引入H5，替代asp.net MVC
2.API層提供統一開發平台Service Gateway。通過此平台統一對外提供服務，並規范服務的開發、管理。並進行安全控制和訪問控制。
3.后台服務提供微服務、分布式服務平台，整合現有的后台服務。提供服務的統一管理和發布部署，后續實現服務治理。
4.提供監控預警平台，從UI、API、Service、基礎設施多層對系統進行360度無死角監控和預警。與Service Gateway、服務框架對接，實現服務端的全鏈路監控和數據聯查。
5.搭建配置中心，把所有系統監控配置進行集中管理，降低管理配置項帶來的負載性。
6.搭建消息應用中心，提供定時任務、異步任務處理等功能。
7.另外，搭建一套補丁平台，對系統的補丁進行集中管理，並實現自動部署安裝的功能。
大體的架子和規划有了，后續再詳細介紹每一塊的落地方案。
vl 2016-9-18