大專案為服務架構設計思維

根據目前產品存在的問題，針對快速開發、海量使用者、大量資料、低延遲等網際網路應用的實際需要，通過對業務架構、系統架構、基礎架構、技術架構進行分析，採用先進實用的微服務SOA架構重構智慧校園、數字化校園等產品，徹底解決系統解耦、效能低下等問題，而且支援雲端計算部署，可以滿足高併發、高可用、高穩定和高安全等效能要求，提供強大的saas和網際網路訪問服務。由於採用微服務架構，各個服務模組化編寫，具有高內聚低耦合的優勢，便於靈活更新升級，而不會影響其他業務。一套程式碼，同時支援移動應用和pc應用，提高效率，節約成本。這個架構還便於AB灰度釋出產品，提高開發效率，對測試、運維管理也可以顯著提高效率。微服務通過REST方式提供訪問,產品實現重構，進行服務劃分，可以充分使用現有的程式碼。.NET產品使用ASP.NETWeb Api提供rest服務，使用RestSharp訪問服務；java產品使用restEasy提供rest服務，使用httpClient訪問服務。服務實現統一的註冊、治理、發現，通過serviceAdapter統一呼叫。這個架構有助於對外提供訪問API，提供open的開發支援，有利於形成公司的產品優勢。

這是一個非中心化微服務架構，網際網路時代，企業的核心就是效率。傳統企業服務匯流排是中心化的架構，這會導致效率低下、穩定性差，採用去中心化架構，教育顯著提高效率，增強安全性和穩定性。採用資料庫儲存服務資訊，採用訊息佇列處理事務，特點在於多次呼叫服務，確保成功，採用統一的介面呼叫服務，對服務進行管理。

 

這個架構為使用者提供的一個核心價值，在於隨著系統機器數量的不斷增加，處理效能呈線性上升，可靠性呈指數級上升，而運營成本不會隨著機器的增加而顯著增加。為了實現這個價值，企業級網際網路架構呈現了服務化、去中心化、非同步化、高可用、資料化運營等五大特徵。而且對於開發可以提高效率，產品修改設計方便，測試、運維簡單。

服務化的技術體系提供企業級分散式應用框架來實現原有業務面向網際網路服務化改造，改變現在的豎井式、煙囪式的系統建設，讓應用開發週期更短，並且能夠讓IT應用系統進一步的促進業務發展。採用去中心化架構，沒有核心流量匯入點，這樣帶來的負載更小，故障影響的範圍也更小，能夠大幅降低去中心化應用系統的運營成本。

2.1.1目前現狀

1)沒有服務化，各產品系統獨立開發，程式碼複用率低，系統之間互相呼叫，耦合嚴重，系統解耦獨立部署困難。

2)應用間資料複製嚴重，資料不一致性嚴重

3)基礎元件薄弱，日誌，監控系統不完善

4)功能模組定義混亂，包含大量介面，介面定義重複

5)大容量訪問下無法提供可靠性服務

6)開發saas網際網路功能的產品迫在眉睫，需要滿足快速開發、靈活升級、高效能、高可用、高穩定、簡化運維等更高的需求。

2.1.2亟待解決

1)核心系統全面服務化：招生、教務、學籍、資產等系統分解為核心服務和基礎服務。

2)基礎元件：服務化框架，分庫分割槽，快取元件。

3)加強監控，日誌系統。

4)非同步化並行，限流，分流，降級，壓力測試，異地災備。

5)資料庫統一規劃優化。

6)平臺和業務功能設計，遵從三個維度定義架構設計的原則：

a. 內容可擴充套件性

針對智慧校園各個功能提供動態支援。

針對夢想學堂營銷活動提供動態可支援性。

b. 功能可擴充套件性

針對各種擴充套件功能需求，系統支援統一的方式擴充套件新的能力，並提供統一的管理。

c. 系統可擴充套件性

支援對大量使用者訪問能力的平滑支援。

支援高可用，高安全，並具有高的系統恢復能力。

以基於“雲”模式的服務端IT架構框架為整體策略，採用基礎架構和功能實現分離的原則：

a. 服務端：構建統一的雲模式IT基礎設施

基於標準化的設施，分別構建統一的IAAS層和PAAS、SAAS層，實現資源的共享，提高未來業務應用開發的效率和可維護性，並提高整體裝置的利用

b. 大架構模式：實現基礎架構和功能實現分離原則

功能開發團隊

採用簡單工具

關注流程

關注功能實現

關注服務劃分和治理

關注資料處理

關注使用者體驗

系統開發團隊

關注系統穩定性

關注系統效能

關注系統擴充套件性

關注系統可維護性

關注系統可靠性

2.1.3改進辦法

（1）核心業務抽取出來，作為獨立的服務對外服務，實現架構和程式碼重構。

（2）核心服務呼叫基礎服務，充分複用程式碼，減少工作量，便於修改維護，把握好服務的粒度劃分，過多的服務訪問會影響效能，過少會影響靈活性，需要對業務進行細緻梳理，合理確定核心服務和基礎服務。

（3）服務模組獨立部署，充分解耦，各系統靈活使用不同服務，可以獨立部署，徹底解決系統耦合不能單獨銷售問題。

（4）各層彼此獨立，修改各層不影響其他層。

（5）資料庫讀寫分離、分庫分割槽

（6）大量使用快取，提高訪問

（7）系統間非同步互動

（8）服務對等隔離

（9）移動和pc產品的優化

APP實際上和PC端瀏覽器是對等的，PC端應用有服務端，APP也需要自己獨立的服務端，兩個服務端都需要針對自身的特點，獨立開發，獨立部署，同時實現邏輯和物理層面的解耦，從架構層面徹底擺脫PC思維移動化。

1. 統一服務

核心邏輯從Web應用剝離出來，進行服務化改造，服務實現時不區分PC和移動，APP和Web應用都依賴於這些服務，一套介面，多方呼叫。

2. 統一閘道器入口

提供統一的移動閘道器，所有APP呼叫指向此閘道器，閘道器包括通用層、介面路由層、適配層。

3.通用層

通訊協議適配、資料封裝、安全、監控、日誌這些系統級功能，每個介面呼叫都需要同樣邏輯，這些功能統一由閘道器前置處理，避免重複開發。具體實現時，每個通用處理邏輯封裝成攔截器，遵循統一的過濾介面，並且做到可配置，閘道器依次呼叫這些攔截器，這樣可以支援通用邏輯的靈活擴充套件。

攔截器介面定義如下：

Object filter(Object input) throws Exception

介面路由

經過通用邏輯預處理後，移動介面請求將進一步分發給後端處理（各個Adapter）。URL和Adapter在配置檔案裡做對映，分發邏輯根據請求中的URL資訊，找到對應的Adapter，然後把請求交給Adapter處理。

配置例子如下：

www.Website.com/search SearchAdapter

www.Website.com/detail DetailAdapter

4.服務適配

外部移動介面和內部SOA介面的輸入輸出格式以及通訊協議很可能不一樣，比如前者經常是HTTP+JSON格式，後者可能是Hessian+二進位制格式，Adapter首先用於移動介面和內部SOA介面的適配，除此之外，Adapter還可能對多個SOA服務做聚合，對APP提供粗粒度的資料，以減少遠端網路呼叫次數。實現上一般每個業務系統有一個Adapter，負責本系統移動介面的呼叫適配。

Adapter介面定義如下：

Object adapter(Object input) throws Exception

Adapter物理上是jar包，由各個業務線研發團隊提供，作為相應SOA服務的前置，最終所有Adapter集中部署在閘道器，閘道器本身支援水平擴充套件。

（10）關鍵點：

1.服務註冊中心，zookeeper叢集作為分散式排程中心，各個服務註冊在zookeeper之上，註冊內容包括服務的請求url，請求ip地址和埠，服務元件名稱，註冊時間等；

2.Gateway，服務閘道器作為系統的入口，具有服務轉發、授權驗證、負載均衡等作用，可以使用高併發框架netty實現高速轉發等；

3.訪問控制服務，使用者首先需要獲得系統授權才可以訪問業務服務，授權通過token來實現；

4.業務服務1~N，是系統內具體業務元件的劃分割槽別核心服務和基礎服務；

5.資料服務，實現資訊的修改、共享等；

6.配置中心，整個系統的配置均位於配置中心，元件通過訪問配置中心獲取配置引數；

7.監控系統，檢測服務、redis、zookeeper叢集等的各項狀態，自動告警和智慧調節服務，防止伺服器雪崩；

8. 訊息佇列系統，支撐全部系統；

9.服務治理、發現、呼叫。

10.服務呼叫通過serviceAdapter介面完成。

2.2關鍵功能

1. 通過重構智慧校園架構，完成原有功能及新增功能。架構分為應用層、核心服務層、基礎服務層、資源層及ecloud層。

2. 應用層主要實現與Web頁面、移動客戶端的介面互動。

3. 服務層主要把核心業務模組化、服務化，這裡又分為兩類服務，一類為基礎服務，定義是不依賴任何其他服務的服務模組，表示它們的獨立性，另外一類為核心服務，通過各種原子服務和業務邏輯的組合，完成的Composite服務，定義統一的介面規範訪問。

4. 資源層主要是資料和檔案的儲存，包含通用的快取資源Redis以及持久化資料庫儲存MySQL、HBase，及分散式檔案系統TFS等。

5. 水平分層有一個特點，依賴關係都是從上往下，上層的服務依賴下層，下層的服務不會依賴上層，構建了一種簡單直接的依賴關係。

6.Ecloud層提供一門戶、單點登入、使用者許可權管理中心、統一資料中心、統一認證中心、運維管理中心、訊息推送中心、配置管理中心、統一註冊及驗證、統一登出、報表服務、統一會話、後設資料、日誌、快取及通用基礎功能等功能。產品的上層服務層呼叫ecloud的功能，統一程式碼，充分複用，便於修改。

2.3關鍵質量屬性

l系統中需要同時滿足移動端產品以及pc產品的需求。

l 系統需要支援高效能、高併發性、高可用性的設計實現方案。

l 安全性：應保證系統中關鍵敏感資訊的安全性，包括但不限於使用者名稱密碼憑證、Ticket資訊等。

l 支援5千萬人線上，大部分頁面同時最多5000個併發請求，事務成功率不低於98%。

l 系統保證7*24 小時執行，穩定可靠；

l 平均延時：普通頁面，小於2秒，最大不超過5秒；查詢頁面，小於3秒，最大不超過17秒；

l 支援負載均衡、可擴充套件性。

l 運維自動化，實時監控系統，及時發現異常和故障並自動告警。

l 系統故障恢復時間不超過1小時。

2.4平臺價值

這個基礎平臺以先進的教育教學理念和技術作為依撐，以“應用導向”為基本原則，以探究教育教學的本質為主要精神，以教學資源整合為重要手段，以教學資源的開放共享為擴充套件方向，實現教育教學與IT技術的深度融合，採用微服務架構實現一個共享可複用的統一框架，是具有擴充套件性、相容性、前瞻性的底層平臺，實現6大產品共享，滿足快速開發、避免重複開發的需求，開創產品創新的新模式和新途徑，更好的為產品開發和部署、運維提供服務。

l 平臺共享資料為各個子系統共同呼叫的資料，減少各子系統間資料的呼叫，減少系統間的耦合性，達到“強內聚，低耦合”的效果；

l 可實現資料一次輸入，多個子系統使用，消除資訊孤島，減少資料庫伺服器工作量，提高整體使用效能；

l 提供統一的開發框架，提高開發效率，避免重複開發，節約成本；

l 便於部署，實施和運維；

l 整合6大平臺，形成強大的合力。

l 形成一個產品，用於教育、金融等產品的開發和管理。

l 服務模組化設計，便於根據需求組合使用。

l 服務統一註冊、發現、治理。

l 便於叢集部署和負載均衡，提供強大的併發支援和高可用。

2.5約束條件

a)系統穩定、高效，可支援校園內外各種不同使用場景下的併發操作。

b)系統有良好的擴充套件性：在增加新的功能時舊有模組不做改動或稍作改動即可完成整合，部署更新不影響其他業務。

c)提供資料介面：便於其他產品或第三方廠商系統進行整合。

d)模組化：各個功能部分按模組開發，模組彼此解耦。

e)配置化：可根據客戶實際需求，配置不同引數。

f）支援6大平臺的開發和執行，支援Windows和Linux系統。

g） 採用B/S架構，與外部業務系統之間使用RestfulAPI進行互動，使用Spring MVC、java、c#語言進行開發。

h)需要支援高效能、高併發、高可用和高穩定的需求。

2.6資訊標準

資訊標準建設是數字化校園建設的重點之一，對推進數字化校園建設，保證 資訊的交流與共享，有著重要的意義。鑑於各個學校的特殊性，因此所採用的資訊標準必須保證和國家以及教育部的資訊標準相相容。

《教育管理資訊化標準》的頒佈為教育部門進行教育資料總體的規劃和組織，建立統一的資料平臺提供明確的規範和標準，它將帶動教育管理資訊儲存、訪問、更新、傳遞方式的變革，進一步減輕學校人力資源和財政管理的負擔。

根據上述資訊標準的要求，本公司將結合國家和行業標準以及學校的實際要求，制定出《學校資訊化資料標準》。該資料標準在全校範圍內作為資料編碼的依據和標準，為資料庫設計提供了類似資料字典的作用，為資訊交換、資源共享提供了基礎性條件。

標準制定的實施過程如下圖所示：

制定完成後的高校資訊標準有以下內容，如圖所示：

1. 架構設計原則

3.1架構設計對後續工作的要求

l 系統採用B/S架構，需要使用spring MVC、java、c#語言進行開發，提供RestfulAPI和其他系統進行整合和互動。

l java系統採用java技術構建，應用伺服器僅支援部署在Windows +tomcat8平臺，但並不限定使用Ecloud系統服務的其他相關係統的作業系統平臺,.net系統使用c#開發。

l 系統功能需要支援高效能、高併發性、高可用性的方案。

3.2架構設計原則

l SRP（Single Responseble Principle）即單一職責原則，每一個服務提供者僅暴露自己職責範圍內的介面，操作職責範圍內的DB，不繼承其他服務提供者的協議。簡單點說，該你乾的才去幹，不該乾的呼叫其他人的服務來幹。

lRESTful，作為Web Service的替代者，其面向資源的特性註定是為微服務而生的，介面設計符合REST設計原則將使服務易於理解和接受。需要注意的是，靈活的使用，如保持請求風格一致，一般用GET/POST，少用DELETE/PUT，保證同類資源字首的一致性等。

l 分離關注點，將應用劃分為在功能上儘可能不重複的功能點。主要的參考因素就是最小化互動，高內聚、低耦合。但是，錯誤的分離功能邊界，可能會導致功能之間的高耦合性和複雜性，

l 最小知識原則，一個元件或者是物件不應該知道其他元件或者物件的內部實現細節。

l 不要重複你自己，你只需要在一個地方描述目的。例如，特殊的功能只能在一個元件中實現，在其他的元件中不應該有副本。

l 最小化預先設計，只設計必須的內容。在一些情況，你可能需要預先設計一些內容。另外一些情況，尤其對於敏捷開發，你可以避免設計過度。如果你的應用需求是不清晰的，最好不要做大量的預先設計。

l 高內聚低耦合：將不同的功能程式碼分離開來，更利於系統的設計和開發，同時為可能的變更提供了更小的單元，十分有利於系統的維護和擴充套件。新增的自定義公式必須符合該原則。

l 可視作一個獨立的系統，為減少重複的開發、統一管理，提高整體開發效率而存在。

1、開放性

基礎平臺應具有良好的開放性和相容性，採用面向服務的公共管理平臺，提供REST API介面，通過統一資訊門戶、統一許可權管理和公共資料交換，整合、整合各類應用系統和各種資訊資源，實現資源和平臺的開放共享。

2、先進性

基礎平臺整體建設採用先進的理念和思想、成熟的技術與設計方法，符合當前潮流與未來發展趨勢，以便跟上資訊科技的發展，具有較強的生命力，具有長期使用價值。

3、易用性

基礎平臺建設的核心目的就是“易用”，須堅持易用的設計原則，緊緊圍繞開發的實際需求，在滿足產品要求的前提下，以儘可能少的投入，取得儘可能大的效益。

4、可靠性

基礎平臺支撐著整個系統的日常管理、教學、生活、科研、文化、服務、資訊保安和資源建設等方方面面，必須具有高可靠性、高容錯性和強大的資料處理能力，使用成熟的熱備份技術和叢集技術，以確保不間斷執行、確保區域性出錯不影響整體、確保快速響應。

5、穩定性

基礎平臺必須具有良好的穩定性，保證持續執行時間長、故障間隔大、無故障時間長。

6、可擴充套件性

基礎平臺必須具有良好的可擴充套件性，對於校園管理模式的變化、管理體系的調整、業務流程的改變等，能夠通過規則引擎簡便配置即可快速適應變化，滿足學院的需求。

7、易升級性

基礎平臺採用版本控制機制與更新包技術，能夠簡便快捷地完成整體或部分的版本升級。

8、易維護性

基礎平臺的使用者包括部門的管理人員、工程師，必須堅持易維護的設計原則，確保結構清晰、介面友好、操作簡單、維護方便。

9、安全性

構建全方位、多層次、完善的安全保障體系，通過安全制度建設和安全教育培訓，在保證物理安全和網路安全的基礎上，保證資料安全。根據基礎架構及各個軟體系統的設計要求，採取不同的安全策略與安全措施，保證系統安全。

10.保密性

基礎平臺通過身份認證、角色定義與許可權分配，確保每個使用者能且只能訪問相應的資訊資源與應用服務。

11．可管理性

基礎平臺具有高度可管理性，使得開發人員的開發簡便快捷。

12． 逐步完善，平滑過渡

要根據現有的產品情況，逐步開發實施，平滑過渡。

13．遵照 SOA 的設計理念，建立鬆散耦合的整合與應用

14．可持續建設

平臺在滿足現在開發需求的同時，能夠兼顧公司的發展現狀，設計一套能夠滿足未來一段時間發展的標準，並且在全域性建設過程中能夠持續的升級、維護標準。

15．服務元件及中介軟體一體化、通用化。

2. 邏輯架構檢視

系統採用4層微服務架構，分別是展示層、應用層、服務層、資料資源層。

4.1職責劃分與職責確定

按照“高內聚，低耦合”的思想，將不同的功能程式碼分離開來，更利於系統的設計和開發，同時為可能的變更提供了更小的單元，十分有利於系統的維護和擴充套件。系統採用微服務架構，分5層，分別是分別是展示層、應用層、服務層、資料資源層、ecloud層。

4.2介面設計與協作機制

Ecloud系統中，管理系統的實現技術類似，通過各個分層之間的協作來實現增刪改查。下圖以角色管理的增加功能為例說明各個分層之間的協作機制。

1. 使用者通過Management UI增加角色頁面一個角色，Management UI呼叫應用層Role Business的Add方法，同時把接收到Model實體物件傳遞到過去。

2. RoleBusiness層呼叫核心服務層和基礎服務層服務，同時把Model實體物件傳遞到過去，進行處理。

3. RoleID逐層返回給Management UI。

4.3重要設計包和埠

專案的包名和類名需要規範化，按照統一的約定完成。

名稱

說明

com.xx.platform.cache

快取元件包，包含快取相關類。屬於公司級的公共元件

com.xx.platform.common

Ecloud專案的公共功能類

com.xx.platform.dto

顯示業務實體類

com.xx.platform.vo

持久化實體類

com.xx.platform.dao

資料訪問層

com.xx.platform.service

服務邏輯層

com.xx.platform.controller

業務邏輯介面層元件，應用真實的業務邏輯類

com.xx.platform.exception

系統的異常類

com.xx.platform.interceptor

攔截器類

com.xx.platform.utils

系統的工具類

com.xx. platform.configuration

系統的配置類

1. Dao類分為介面XXDao和實現類XXDaoImpl及資料庫對映檔案XXDao.xml。

2.Service類分為介面XXService和實現類XXServiceImpl。Service分核心服務和基礎服務。

3.Controller類繼承基類BaseBiz。

4.Vo和Dto類繼承基類BaseVO， Dto面向頁面和業務處理，Vo面向持久化。

PageModel類為分頁類。

5.前端頁面採用freemarker生成html，簡單高效。

6. Exception 類繼承基類BaseException。

7.儘量減少埠，充分複用現有埠。

4.4開發執行及使用

採用java和.NET開發，部署在tomcat8和iis上，

Java產品使用先進實用穩定可靠的jdk1.8+spring4+mybtis3+jquery1.9.1+freemarker-2.3.21+mysql5.6框架。支援ie8+、firefox、chorme瀏覽器，使用restEasy提供REST服務；.NET產品使用visiostudio開發。

3. 物理架構檢視

5.1物理拓撲

系統理想的網路部署圖如上所示。需要說明的是：

1. 應用伺服器、CAS伺服器、service伺服器、管理伺服器、資料庫伺服器部署在一個區域網內部。

2. 資料庫系統採用主從結構，保證高可用性。

3. CAS伺服器負責單點登入功能，需要保證高可用性，因此至少需要部署包含兩臺伺服器的叢集。

4. 管理伺服器作為部署Management UI的WEB伺服器，通常情況下部署一臺伺服器即可。

5. 系統管理員、使用者通過Internet與分別與管理伺服器、應用伺服器連結。

6. 為了提供資料訪問的效能，需要部署快取系統Redis。

7. 採用docker、k8s部署到容器，實現叢集的自動負載均衡和管理，提高效能和穩定性，簡化運維。

5.2軟體到硬體的對映

l 應用伺服器：執行業務系統。WindowsServer 2013、iis+tomcat8

l service伺服器：執行服務系統。WindowsServer 2013、iis+tomcat8

l 管理伺服器：執行管理系統。WindowsServer 2013、tomcat8

l 資料庫伺服器：執行資料庫系統。Linux、MySQL5.6、Redis3。

l 快取伺服器：執行Redis系統。Linux、Redis3。

5.3優化部署

為了減少硬體的成本，可以把管理系統部署在應用伺服器上，省去管理伺服器。各個模組可以分別部署，便於靈活修改升級釋出。Service伺服器可以根據訪問量進行叢集和負載均衡。

想了解架構專案的，可以私信我哦！

1 SpringBoot+ 高併發訊息處理 EDM?專案 實戰

2 SpringBoot ELK?分散式 資料分析

3 Netty?高 併發 UTS?專案實戰

4 SpringCloud?微服務+NoSQL+ 負載均衡平臺設計

四大專案。