信息化平臺架構設計

1、爲何須要信息化平臺

• 若是沒有信息化建設平臺，每次新開發一個系統時，由不一樣的負責人負責開發就會有不一樣的開發規範，真可謂是八仙過海各顯神通。形成系統與系統之間進行對接十分困難，後期運維及交接困難度加大。
• 若是沒有信息化建設平臺，每次新開發一個系統時，即便同一個項目負責人，在不一樣時期也可能採用不一樣的開源框架。開源框架有好有壞，規範也是天差地別，若是對所用的開源框架了解的不夠充分，那將是災難性。由於系統的bug千奇百怪，就像聊齋志異同樣，後期運維的成本也是至關大的，若是項目耦合度高，都有可能出現項目負責人都沒法運維的現象。
• 若是沒有信息化建設平臺，每次新開發一個系統時，都要考慮架構設計，權限驗證等問題，開發者在前期都要浪費不少時間在這些問題上，增長了項目延期的風險。
• 若是沒有信息化建設平臺，每次新開發一個系統時，都要花費不少時間在系統的基礎設施層上，如緩存，日誌 、郵件、性能監控、文件上傳下載等。容易形成各個系統的基礎設施層的代碼亂七八糟，使開發者暈頭轉向，增長開發風險，也下降了系統的穩定性。
• 若是沒有信息化建設平臺，每次新開發一個系統時，可能出現一個用戶多個帳號，多個密碼，用戶的體驗度也必將不好。

2、信息化平臺架構設計圖

3、介紹一些在企業中經常使用而且扮演重要角色的系統

一、統一權限管理系統

　　 若是要想打造企業的信息化建設平臺，打造統一權限管理系統，能夠說是萬里長征的第一步。

　　 對於開發者來說，若是有這麼一個系統，那麼咱們每一個系統均可以採用同一種的權限管控方式。咱們開發者在開發系統時，就徹底不須要操心權限的問題。所需的工做量僅僅是將公用的jar包或者dll引入到項目中便可，開發者在須要權限驗證的地方加上註解（java）或者特性（.Net）或者其餘資源標識。

 　　對於系統運維人員來說，能夠在統一權限管理系統中管理每一個用戶的每一個系統的權限。用戶註冊及用戶權限的管理能夠交由部門負責人去負責，也能夠作一套權限變動申請流程。這樣的話，即下降IT運維成本，又能夠增長用戶體驗度。他還有一個顯而易見的好處，若是某我的離職了，能夠一鍵清除他在每一個系統中的賬號權限，由於他的賬號只有一個！

二、單點登陸系統 

 　　單點登陸（Single Sign On），簡稱爲 SSO，是目前比較流行的企業業務整合的解決方案之一。SSO的定義是在多個應用系統中，用戶只須要登陸一次就能夠訪問全部相互信任的應用系統。

　　單點登陸是在多個應用系統中，用戶只須要登陸一次就能夠訪問全部相互信任的應用系統的保護資源，若用戶在某個應用系統中進行註銷登陸，全部的應用系統都不能再直接訪問保護資源，像一些知名的大型網站，如：淘寶與天貓、新浪微博與新浪博客等都用到了這個技術。

1. 單點登陸涉及SSO認證中心與多個子系統，子系統與SSO認證中心須要通訊（交換令牌、校驗令牌及發起註銷請求等），子系統中包含SSO的客戶端，SSO認證中心是服務端
2. 認證中心與客戶端通訊可經過 httpClient、web service、rpc、restful api（url是其中一種） 等實現
3. 客戶端與服務器端的功能
   1. 客戶端：
      1. 攔截子系統未登陸用戶請求，跳轉至sso認證中心
      2. 接收並存儲sso認證中心發送的令牌
      3. 與服務器端通訊，校驗令牌的有效性
      4. 創建局部會話
      5. 攔截用戶註銷請求，向sso認證中心發送註銷請求
      6. 接收sso認證中心發出的註銷請求，銷燬局部會話
   2. 服務器端：
      1. 驗證用戶的登陸信息
      2. 建立全局會話
      3. 建立受權令牌
      4. 與客戶端通訊發送令牌
      5. 校驗客戶端令牌有效性
      6. 系統註冊
      7. 接收客戶端註銷請求，註銷全部會話

三、日誌系統

　　日誌系統對於任何項目都是必不可少的，不管對於測試階段的debug,性能測試，執行時間，操做記錄仍是線上的問題排查，訪問記錄等，日誌系統都扮演着重要的角色。

　　日誌系統能夠手機各個系統生產的日誌記錄，而且能夠在線查看系統日誌，特別是錯誤日誌最最重要。當日志系統發現系統中出現錯誤日誌記錄時，日誌系統將會給開發人員發送報警郵件，並將錯誤日誌詳細消息一併抄送給開發運維人員，運維人員也能夠打開日誌系統查看各類相關日誌。小編曾用過使用kibana作的日誌系統，給各個業務系統的運行保駕護航，效果那是很是給力的。

四、監控系統

 　　做爲開發者活系統運維工做人員，會受到用戶的一些反饋信息，好比系統不能使用、某個功能不能使用、查詢速度很慢、頁面容易卡死等等，若是公司存在監控系統，咱們就能夠監控服務器的各類新能。其實最多見的監控就是服務心跳，監控服務是否正常運行，服務是否能順利的鏈接數據庫。

　　我認爲一個健全的監控系統應該包含檢測各個服務器的CUP、內存、Redis、服務、接口響應時間、Sql語句等等。

　　若是咱們有CPU的監控信息，咱們就能夠實時在線的觀測多臺服務器的性能，經過檢測信息咱們也能知道系統卡頓是否是CPU的問題。

　　若是咱們有服務、接口響應時間、Sql語句的監控信息，咱們就能夠準確的判斷出是數據庫執行sql耗時，仍是服務代碼寫的有問題。由於咱們有監控的數據，因此基本上能夠很清晰的定位到咱們的系統到底哪裏除了問題。

　　若是咱們有服務心跳的監控信息，當服務響應慢或者服務中止的時候，監控系統就能夠及時的監控到，從而能夠及時給開發活運維工做人員發送郵件。

五、服務註冊中心

 　　服務註冊中心，就是將服務的信息註冊到該系統上。客戶端去服務註冊中心尋找服務的具體地址，而後客戶端在更具服務的地址去調用具體的服務。

　　雖說起來很簡單，可是他起的做用很大。對於運維來說，最明顯的做用就是我能夠隨意更換服務地址，假如說A服務器不能用時，我能夠將系統的服務地址所有換成B服務器。對於開發者來說，能夠大大的簡化代碼複雜度，由於我能夠將服務與服務相互隔離開，不用相互應用就能夠相互調用，從而大大的簡化了開發，使服務更加的輕量級。說白點他就是一個RPC框架，或者理解成企業服務總線（ESB）均可以（雖然有點區別）。而且咱們開發者能夠依託這個系統輕鬆的實現負載均衡技術，在這裏我十分推薦Dubbo + Zookeeper，功能很強大，很齊全。

六、任務調度平臺

 　　不少業務場景須要咱們某一特定的時刻去作某件任務，定時任務解決的就是這種業務場景。好比，晚上一點統計前一天的訂單或者生產數據，並生產報表，而後在早上7點的時候發送郵件給相關領導。生產數據庫與報表數據庫同步數據，每晚2點執行。每隔五分鐘檢查Redis中日誌信息，並將其轉移到數據庫中等等。

　　記得剛畢業那會，想要作一個定時任務，只會在數據庫中寫job或者使用Windows任務。雖然說能夠實現任務的定時執行，可是他的侷限性很大。好比數據庫的job，他只能處理數據庫端的資源，而且數據庫的資源屬於稀缺資源，最好不要佔用數據庫的資源，可是若是你的服務器很好，數據庫也比較空閒，那用job來處理數據也是能夠的，可是後期運維會有點痛苦。windows定時任務靈活度不高，我很難在線看到任務的執行狀況，我也很難作到任務的動態加載、卸載、隔離等。當我想要作一個多節點集羣的任務調度時，是很難作到的。而且若是我有多臺服務器都是要作定時任務，那麼這些任務時很難管理的，這也會讓運維人員很是頭疼。

　　quartz是一個很是優秀的任務調度框架，支持Corn表達式，能夠方便快捷的利用多臺服務器來完成公司內的定時任務的執行，網上也有不少優秀的開源的任務調度系統。

七、報表系統

 　　報表系統雖然佔用程序員的工做量並不大，可是他在公司中所起的做用的很是巨大的。做爲一家企業的老闆、領導層，他們不是很關注系統錄入數據方便不方便，列表是否使用了分頁技術等等（若是系統作的真的很很差，老闆也會很關注的），老闆或者管理者須要看到系統中統計出來的數據來幫助他們作出決定來管理企業，企業運行情況老闆是很關心的，若是有這麼一個報表系統，老闆能夠很方便的查看到公司各個方面的運營狀況，能夠幫助老闆或者領導及時發現問題。從而在老闆的眼中，企業的信息化建設是很是重要的。

八、內容管理系統（知識庫）

 　　內容管理系統，主要是將與員工的工做相關的信息記錄到系統中，他的工做有哪些，每一個工做有哪些步驟，每一個步驟如何完成等等，整理成具體的的文檔存入系統中。好比一個HR員工，如何從打卡機中拿到員工的打卡記錄，這些記錄信息應該作哪些數據清洗操做，而後登錄到考情繫統中，在哪一個位置導入處理後的打卡信息，如何檢查導入後的考情信息是否正確等等。

　　若是有這樣的系統，企業中員工離職交接問題就會變得很簡單了，交接成本也會下降，也不用擔憂離職員工手裏有沒有交接的內容，由於全部的內容均記錄在系統中。

　　對於開發者的好處是，系統的表結構、接口說明、系統設計文檔，系統操做文檔等等均可以存入知識庫中，方便程序員快速找到相關的文檔，迅速解決問題。

九、項目管理系統

 　　以前使用過一套開源的項目管理系統--Redmine，具體業務人員在Redmine上提需求，開發人員更具Redmine上的需求開發功能。並非說業務人員僅僅在Redmine上提好需求就能夠了，還須要開發人員或產品經理去和業務人員好好的溝通，這才能理解需求。這樣作的好處是能讓提需求的人員重視這個問題，由於沒提一次需求，變動一次需求，系統上都是有記錄的。自從使用了這個系統，我發現業務員提需求很嚴謹，不會張口就來，這真的是開發人員的福音啊。

　　有效嚴謹的需求對咱們開發的幫助是很大的，雖說在開發系統以前，軟件開發人員應該比業務員還要了解業務，這樣才能更加有效的防止用戶該需求。我在剛踏入這一行的時候，有一位前輩和我講過這麼一句話，客戶改需求，80%的責任屬於咱們開發人員，20%屬於客戶。由於客戶不懂軟件，而咱們是作軟件開發的，因此咱們應該比業務員更加的瞭解業務！

　　項目管理系統能夠用開源的，也能夠本身研發，配合內容管理系統一塊兒使用，對系統的建設更加的有好處。另外，項目管理軟件還能有效的量化咱們開發工做，指定項目開發計劃，保證項目按時上線！

十、文件中心服務系統

 　　文件很差管理----在Web系統中，上傳的文件每每放在UPLOAD目錄裏,而後就沒有下文了,後期管理起來只能經過Windows的資源管理器來管理了,這種方式簡單的系統應付起來還行，稍微複雜點就有點力不從心了。若是作負載均衡，當前登陸人的頭像圖片就很難管理。

　　不太方便擴展----或者說擴展起來比較費事，比方說作斷點續傳，秒傳，作文件預覽，等等。

　　重複工做太多----每次開發一個新系統,上傳這塊都要所有搞一遍,感受太費勁,之後還很難再繼續升級 只要系統涉及到頻繁的文件上傳下載可能就都會面臨這些個個問題，既然這樣，爲何不把這一塊單獨拎出來開發成一個服務+系統呢。

　　

 

Web項目開發建議：先後端分離

　　若是一家公司有java團隊，又有.Net團隊，那麼再開發web項目時，最好使用先後端分離技術。java項目最好不要用jsp，也不要用如今很是火的Thymeleaf，雖然SpringBoot推薦開發者使用Thymleaf，可是.Net團隊是不會使用Thymeleaf這樣的前端框架。一樣的.Net也不要使用aspx，更不要使用ASP.NET MVC Razor。

　　其實也並不是不能，若是在html中嵌入一個iframe控件，也能夠兼容jsp，Thymeleaf，ASP.NET MVC Razor等，只是說最好不要。

　　可使用傳統原生的html + css + js的技術，也可使用AngularJS、VUE等技術，他們都是很是優秀的前端框架。這樣的話，兩個團隊之間能夠相互幫忙寫前端頁面，或者交由專門寫前端的開發人員負責開發。前端開發利器WebStorm，很是好用，沒用過的能夠體驗一下。