為了使業務**介面的復用性以及服務終端唯一性，設計了一套關於業務呼叫的架構。架構內容分別是：1、應用服務端 2、**層 3、鑑權中心 4、註冊中心 5、路由服務（分發、構鏈、過濾）6、服務應用 7、資料層 8、計算層
以上圖展示了關於整個架構應用的架構圖，核心內容：
**層，安全門，對一切請求的過濾與分發；
路由層，核心的中樞層，根據預先設定的流程進行組裝分發；
鑑權中心，assestoken做授權處理；
訊息佇列中心，點對點、點對面的發布 ；
監聽服務，監聽訊息佇列，對不同型別的訊息進行分組排序，做處理分發；
現在**伺服器有很多，nginx、apache、jboss等。這邊使用了zuul作為**伺服器。
當乙個ui應用呼叫乙個或更多的後端服務的時候，我們可以用spring cloud建立乙個zuul**
減少開發是非常常見的例子。使用**服務來避免必須的跨域資源共享（cross-origin
resource sharing）和所有的後端需要分別認證的問題。
eureka包含了伺服器端和客戶端元件。伺服器端，也被稱作是服務註冊中心，用於提供服務的註冊與發現。eureka支援高可用的配置，當集群中有分片出現故障時，eureka就會轉入自動保護模式，它允許分片故障期間繼續提供服務的發現和註冊，當故障分片恢復正常時，集群中其他分片會把他們的狀態再次同步回來。
路由層是業務分發的核心模組，類似遙控器，操控服務流程主要功能：
構鏈（將服務請求組裝成鏈）
分發斷路
異常記錄
返回結果
記錄：將失敗在資料庫記錄。
佇列：將失敗資訊型別分裝，傳送到訊息佇列。
返回：最後將結果返回給呼叫者
監聽分組
重試（針對路由訊息）回滾
監聽：監聽訊息佇列，實時監聽**
分組：將訂閱的訊息進行洗滌過濾並分組
重試（分發給路由重試介面）：根據編號取出資料庫的流程步驟，然後進行次數嘗試，如果還是失敗進入回滾。
回滾：資料回滾，根據預先提供的業務回滾介面，進行呼叫回滾
軟體行業 業務 模組 業務邏輯的理解
覺得還不錯，在csdn論壇上找的 面試官 什麼是業務？本人只知道軟體業務，針對不同行業的需求提供最優的內容管理解決方案 面試官 什麼是模組。如果說登入頁面的話，稍微小了點，有了侷限，一般比如做個軟體，這裡舉個例子，物流軟體吧，其中收貨管理 退貨管理 集貨管理 付貨管理，財務管理等就是軟體模組化，更為...
業務模組的設計原則
以下內容是工作中的幾點總結，總結的上下文是在關聯式資料庫的設計環境，還請各位朋友多多發表以下自己的想法。1 模組的最小單位根據乙個完整事務設計 2 模組的最小單位根據乙個完整流程設計 3 模組中，只能應用資料庫的連線，不能夠修改資料庫的連線，最好是在new方法中，獲取資料庫連線。4 業務模組中的演算...
zuul業務檢查相關模組
在使用spring cloud進行微服務開發的過程中，因為微服務之間的訪問只是對資源的訪問，不應該有許可權相關的檢驗，但是對外開放的服務是必須要對沒有使用者所能訪問的資源與操作進行許可權檢驗的。而spring cloud的閘道器服務開源專案並沒有很好地提供業務檢查相關的處理模組，所以我在使用zuul...