在分布式系統中，平衡業務計算的壓力分布，減少網絡上的數據流動，是一種提升性能的手段，請看下面的例子。

1）案例背景

某“機械設計研究所”歷史上在管理模式上采用傳統的層次化垂直結構。但是近年來，隨著用戶對產品更新換代的要求越來越快、質量要求越來越高，在競爭日益劇烈、外部壓力日益增大的形勢下，該所在管理模型上重新定位，打破長久以來形成的垂直結構，形成一種趨向於水平集成的業務模型，使企業能更專註於自己的業務特長，在產品研發時，能更好地利用國內更先進的技術力量，以實現合作方異地協同設計。

為此需要構建一個基於互聯網的符合合作方異地協同設計的信息管理平臺，使得部件設計合作方能夠在早期就介入產品的研發過程，及時獲取產品信息和變更通知，並將相關的信息及時反饋到企業，縮短主要設計部門和合作方的溝通時間，提高合作方在新產品設計中的響應能力，實現各方共贏。這個合作方異地協同設計管理平臺需要有下面一些特點：

具有開放性和可伸縮性，為實現產品的異地、異構設計提供強大支持。

需要實現業務與分布式數據源整合，

需要根據業務發展的需要，實現業務方法的重新編排

需要有效管理各合作方協同設計過程。

通過這個“合作方異地協同設計信息管理平臺”，使研發工程中設計、制造、測試、維護等職能的綜合協調，新產品開發更加有序和有效。

2）初步設計

本設計將面臨如下挑戰：

合作方的參與是不穩定的，系統需要具備可伸縮性的特點。

業務流程是不穩定的，會根據項目與合作方的特點加以改變。

合作方的數據格式具有多樣性，是沒有辦法實施規範的。

異地合作的通信只能采用互聯網，對帶寬有一定限制。

合作設計信息量比較大，對性能有比較高的要求。

為了應對這些挑戰，根據需求分析的要求，初步考慮系統采用面向服務的架構，該系統需要提供三個大的子服務：

項目管理與過程管理子服務（PM&PM）；

工程圖檔與文檔管理子服務（ED&DM）；

配置管理與變更管理子服務（CM&CM）。

這三個子服務相互支持，共同完成合作方協同設計中項目管理、圖檔管理、版本管理以及圖檔修改串行化的業務要求。據此構建了初步的概念性架構。這個架構從業務層面來看，分成完全自治的三個子服務，並且讓合作方的數據以服務的形式提供出來，使整個業務和數據具有很強的可變化性和可伸縮型，其初始架構關系如下圖所示。

這個架構具有如下一些優點：

有利於協調不同的異構數據模型：由於合作方業務的復雜性，使得數據模型間語義與結構存在巨大差異。通過數據總線的集中管理與映射，有利於協調不同的服務領域間的異構數據模型，並且系統具有可伸縮性。

便於實現面向服務的集成（SOI）：通過使用面向服務的架構來解決集成與互操作的問題，將有利於達到根據服務契約對傳統系統進行包裝，創建當前系統集成所需要的新服務的目的。

有利於應對業務的變化：當合作方或者業務發生變化的時候，只需要修改“服務編排”層的業務，就可以方便的實現變更。

本系統通過一個企業服務總線（ESB）和數據總線（Data Bus）統一管理數據使用者的權限、格式轉換以及其它方面的問題，以確保數據的安全性和使用上的方便性。

針對這個案例來說，在合作方位置遙遠、業務非常復雜而且繁忙時，把所有的服務都集中在中央服務中心是不合適的，這樣會嚴重影響服務的性能。為此，把服務按照不同的級別進行分布式配置, 通過合理布局來解決性能問題，如圖下所示。

在這個設計方案中，服務分成兩個不同的層次：

中心服務：這種服務所處的位置在全局數據中心服務器上，其維護的狀態是全局性的，更多的是關註各個合作方之間的協調的業務。在需要多個分布式服務站點參與時，中心服務中的服務職責可以居中協調共同完成業務處理。這種布局的好處在於：一般來說，在同一空間（合作方）中會有大量內部相互協調的操作，而合作方之間的協調在總量上要少得多，這就可以大幅度減少應用服務的網絡流量，提高系統的整體性能。

棧服務：這種服務的所謂全局狀態是有區域性的。例如在同一個合作方範圍內，相當多的業務處理都是在內部進行的，其全局狀態也只是指的這個合作方範圍內而言。我們可以把這類服務（也可能是半服務）在物理上直接置於合作方本身的數據中心，至於這個合作方數據中心提供服務的方式是采用內網還是外網並不重要（大多數情況下這種處理都是置於內網）。

本文出自 “中科院計算所培訓” 博客，謝絕轉載！

架構師提升篇：分布式系統中，如何提升系統性能？