准確的來說，1.0平台的單體應用架構沒有互聯網項目架構一說，傳統的MVC開發模式，簡單的小作坊操作流程，對於每個開發人員來說，只需要關注業務的功能模塊實現而已。在1.0平台運營的半年時間里面，除了業務本身的需求爆炸性的增長，要求開發的迭代迅速，並且每次升級都不應該傷筋動骨，只是模塊化的累加或者在原有的框架里面局部的更新，除了這些，我們還看到了1.0平台本身的基礎性運營配套設施也迫切需要投入進來，以提高平台的運營效率，如日志平台，監控平台，調度平台，報表平台，甚至權限和單點登錄也很需要，所以對於2.0平台的整體規划以上的都應該包含在里面。
一 平台整體能力規划
主要將一些公共的東西全部從原有的業務層里面拆離出來，以平台化軟件包的模式運營。
1. 統一調度平台在項目中很多業務會經常用到，但是1.0平台將調度工作和業務執行工作全部糅合在代碼里面，造成大量的調度工作后期的維護非常不便，而且調度沒法監控目前在運行的調度和距離下次需要執行的調度。統一調度平台可以解決這方面的問題，可以有效的通過管理界面來維護平台的所有調度工作，從設計角度簡單來說，調度的工作歸調度平台，業務的執行歸個各自業務平台（微服務）。
2.統一接口平台主要解決前端應用系統通過統一接口平台獲取數據，不直接與外部系統接口打交道。統一接口平台通過多種方式與外部系統聯接獲取數據並向各前端應用系統提供各種數據格式包，將外部系統有效地隔離在業務系統之外。前端應用系統需要請求的外部接口需要在統一接口平台注冊，開放。每次訪問都會被有效的記錄，實行監管。在前后端分離架構系統里面（其實微服務就是這種），統一接口平台也擔當跨域，和負載均衡的職能在里面。
3.統一日志平台前期主要解決需要登錄到linux服務器，開各種賬號權限查看log日志的麻煩，可以讓開發人員通過管理界面管理日志，查看日志，以提高工作效率，中后期會將ELK日志分析工作引入到平台。
4.統一權限平台主要針對眾多的各種平台 （如上面的調度平台，接口平台，日志平台等）的權限統一管理，這塊配合SSO單點登錄一起使用，如果按照傳統的每個平台分配一個賬號，操作起來比較麻煩，統一權限平台+SSO單點登錄就是解決分配一個賬號，分配權限，可以進入各大平台操作。
5.統一消息平台主要針對內部業務系統的MQ中間件平台管理，和統一調度平台類似，業務的執行歸業務，MQ只負責異步中轉，可通過多種協議接入如http，接入更加堅定快捷，維護更加方便。
6. SSO單點登錄，只需要登錄一次就可以訪問所有相互信任的應用系統，而不用重復登錄。
更多的平台還在規划中，后面的文章也會一 一涉及到，並分享遇到的一些坑和做的一些優化。
二 業務領域拆分
2.0架構體系的業務拆分是個很頭疼的事情，說實話，按照目前具體的項目團隊情況和服務器規划，既不能拆的太細，也不能拆的太粗，只能按照階段去拆去優化，所以我的打算是先按照業務功能稍微粗的來拆，等微服務框架平台整體流程穩定后，再針對每個業務功能細化拆分。
業務領域一旦拆分，意味着也要分庫，由原來的單庫拆分成多庫。
從數據庫架構上來說，考慮到服務器成本，前期還是單機高可用，后期再做分片集群。
三 服務化架構
前端請求到后端大概整體流程（具體以項目實際為准）:
1.訪問html前端頁面,(每個頁面引入checkCookie.js)，如果cookie失效,跳轉到sso單點登錄頁面。
2.sso認證用戶和密碼成功后，生成token寫入redis和cookie。
3.sso跳轉到需要訪問的html前端頁面，(每個頁面引入checkAuth.js)，html前端頁面請求(post請求)統一權限平台,權限平台通過從cookie中獲取token，從token中獲取用戶信息，查詢用戶角色和資源菜單具體權限返回給html前端。
4.html前端根據當前用戶角色擁有的具體資源菜單展示不同的div塊顯示(如果頁面布局麻煩，也可以不改變原先頁面，只是將沒有權限div塊內容屏蔽或者顯示無權限查看)
5.html前端div塊里面的內容展示，通過請求統一接口平台API接口，統一接口平台請求具體java業務平台API接口(微服務)，API網管攔截，驗證token是否在redis存在並合法，如果合法放行，通過客戶端負載均衡到具體微服務獲取具體數據，返回html前端並展示。