信息化平台架構設計

一、為什么需要信息化平台

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

二、信息化平台架構設計圖

三、介紹一些在企業中常用並且扮演重要角色的系統

1、統一權限管理系統

　　 如果要想打造企業的信息化建設平台，打造統一權限管理系統，可以說是萬里長征的第一步。

　　 對於開發者來講，如果有這么一個系統，那么我們每個系統都可以采用同一種的權限管控方式。我們開發者在開發系統時，就完全不需要操心權限的問題。所需的工作量僅僅是將公用的jar包或者dll引入到項目中即可，開發者在需要權限驗證的地方加上注解（java）或者特性（.Net）或者其他資源標識。

 　　對於系統運維人員來講，可以在統一權限管理系統中管理每個用戶的每個系統的權限。用戶注冊及用戶權限的管理可以交由部門負責人去負責，也可以做一套權限變更申請流程。這樣的話，即降低IT運維成本，又可以增加用戶體驗度。他還有一個顯而易見的好處，如果某個人離職了，可以一鍵清除他在每個系統中的帳號權限，因為他的帳號只有一個！

2、單點登錄系統 

 　　單點登錄（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. 接收客戶端注銷請求，注銷所有會話

3、日志系統

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

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

4、監控系統

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

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

　　如果我們有CPU的監控信息，我們就可以實時在線的觀測多台服務器的性能，通過檢測信息我們也能知道系統卡頓是不是CPU的問題。

　　如果我們有服務、接口響應時間、Sql語句的監控信息，我們就可以准確的判斷出是數據庫執行sql耗時，還是服務代碼寫的有問題。因為我們有監控的數據，所以基本上可以很清晰的定位到我們的系統到底哪里除了問題。

　　如果我們有服務心跳的監控信息，當服務響應慢或者服務停止的時候，監控系統就可以及時的監控到，從而可以及時給開發活運維工作人員發送郵件。

5、服務注冊中心

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

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

6、任務調度平台

 　　很多業務場景需要我們某一特定的時刻去做某件任務，定時任務解決的就是這種業務場景。比如，晚上一點統計前一天的訂單或者生產數據，並生產報表，然后在早上7點的時候發送郵件給相關領導。生產數據庫與報表數據庫同步數據，每晚2點執行。每隔五分鍾檢查Redis中日志信息，並將其轉移到數據庫中等等。

　　記得剛畢業那會，想要做一個定時任務，只會在數據庫中寫job或者使用Windows任務。雖說可以實現任務的定時執行，但是他的局限性很大。比如數據庫的job，他只能處理數據庫端的資源，並且數據庫的資源屬於稀缺資源，最好不要占用數據庫的資源，但是如果你的服務器很好，數據庫也比較空閑，那用job來處理數據也是可以的，但是后期運維會有點痛苦。windows定時任務靈活度不高，我很難在線看到任務的執行情況，我也很難做到任務的動態加載、卸載、隔離等。當我想要做一個多節點集群的任務調度時，是很難做到的。並且如果我有多台服務器都是要做定時任務，那么這些任務時很難管理的，這也會讓運維人員非常頭疼。

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

7、報表系統

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

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

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

　　如果有這樣的系統，企業中員工離職交接問題就會變得很簡單了，交接成本也會降低，也不用擔心離職員工手里有沒有交接的內容，因為所有的內容均記錄在系統中。

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

9、項目管理系統

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

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

　　項目管理系統可以用開源的，也可以自己研發，配合內容管理系統一起使用，對系統的建設更加的有好處。另外，項目管理軟件還能有效的量化我們開發工作，指定項目開發計划，保證項目按時上線！

10、文件中心服務系統

 　　文件不好管理----在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，非常好用，沒用過的可以體驗一下。