我的物聯網專案(十三) 2.0平臺架構體系
準確的來說，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前端並展示。