架構師怎麼做技術選型

❶ 資料庫架構選型與落地，看這篇就夠了

隨著時間和業務的發展，資料庫中的數據量增長是不可控的，庫和表中的數據會越來越大，隨之帶來的是更高的 磁碟 、 IO 、 系統開銷 ，甚至 性能 上的瓶頸，而單台伺服器的 資源終究是有限 的。

因此在面對業務擴張過程中，應用程序對資料庫系統的 健壯性 ， 安全性 ， 擴展性 提出了更高的要求。

以下，我從資料庫架構、選型與落地來讓大家入門。

資料庫會面臨什麼樣的挑戰呢？

業務剛開始我們只用單機資料庫就夠了，但隨著業務增長，數據規模和用戶規模上升，這個時候資料庫會面臨IO瓶頸、存儲瓶頸、可用性、安全性問題。

為了解決上述的各種問題，資料庫衍生了出不同的架構來解決不同的場景需求。

將資料庫的寫操作和讀操作分離，主庫接收寫請求，使用多個從庫副本負責讀請求，從庫和主庫同步更新數據保持數據一致性，從庫可以水平擴展，用於面對讀請求的增加。

這個模式也就是常說的讀寫分離，針對的是小規模數據，而且存在大量讀操作的場景。

因為主從的數據是相同的，一旦主庫宕機的時候，從庫可以 切換為主庫提供寫入 ，所以這個架構也可以提高資料庫系統的 安全性 和 可用性 ；

優點：

缺點：

在資料庫遇到 IO瓶頸 過程中，如果IO集中在某一塊的業務中，這個時候可以考慮的就是垂直分庫，將熱點業務拆分出去，避免由 熱點業務 的 密集IO請求 影響了其他正常業務，所以垂直分庫也叫 業務分庫 。

優點：

缺點：

在資料庫遇到存儲瓶頸的時候，由於數據量過大造成索引性能下降。

這個時候可以考慮將數據做水平拆分，針對數據量巨大的單張表，按照某種規則，切分到多張表裡面去。

但是這些表還是在同一個庫中，所以庫級別的資料庫操作還是有IO瓶頸（單個伺服器的IO有上限）。

所以水平分表主要還是針對 數據量較大 ，整體業務 請求量較低 的場景。

優點：

缺點：

四、分庫分表

在資料庫遇到存儲瓶頸和IO瓶頸的時候，數據量過大造成索引性能下降，加上同一時間需要處理大規模的業務請求，這個時候單庫的IO上限會限制處理效率。

所以需要將單張表的數據切分到多個伺服器上去，每個伺服器具有相應的庫與表，只是表中數據集合不同。

分庫分表能夠有效地緩解單機和單庫的 性能瓶頸和壓力 ，突破IO、連接數、硬體資源等的瓶頸。

優點：

缺點：

註：分庫還是分表核心關鍵是有沒有IO瓶頸 。

分片方式都有什麼呢？

RANGE（范圍分片）

將業務表中的某個 關鍵欄位排序 後，按照順序從0到10000一個表，10001到20000一個表。最常見的就是 按照時間切分 （月表、年表）。

比如將6個月前，甚至一年前的數據切出去放到另外的一張表，因為隨著時間流逝，這些表的數據被查詢的概率變小，銀行的交易記錄多數是採用這種方式。

優點：

缺點：

HASH（哈希分片）

將訂單作為主表，然後將其相關的業務表作為附表，取用戶id然後 hash取模 ，分配到不同的數據表或者資料庫上。

優點：

缺點：

講到這里，我們已經知道資料庫有哪些架構，解決的是哪些問題，因此， 我們在日常設計中需要根據數據的特點，數據的傾向性，數據的安全性等來選擇不同的架構 。

那麼，我們應該如何選擇資料庫架構呢？

雖然把上面的架構全部組合在一起可以形成一個強大的高可用，高負載的資料庫系統，但是架構選擇合適才是最重要的。

混合架構雖然能夠解決所有的場景的問題，但是也會面臨更多的挑戰，你以為的完美架構，背後其實有著更多的坑。

1、對事務支持

分庫分表後（無論是垂直還是水平拆分），就成了分布式事務了，如果依賴資料庫本身的分布式事務管理功能去執行事務，將付出高昂的性能代價（XA事務）；如果由應用程序去協助控制，形成程序邏輯上的事務，又會造成編程方面的負擔（TCC、SAGA）。

2、多庫結果集合並 （group by，order by）

由於數據分布於不同的資料庫中，無法直接對其做分頁、分組、排序等操作，一般應對這種多庫結果集合並的查詢業務都需要採用數據清洗、同步等其他手段處理（TIDB、KUDU等）。

3、數據延遲

主從架構下的多副本機制和水平分庫後的聚合庫都會存在主數據和副本數據之間的延遲問題。

4、跨庫join

分庫分表後表之間的關聯操作將受到限制，我們無法join位於不同分庫的表（垂直），也無法join分表粒度不同的表（水平）， 結果原本一次查詢就能夠完成的業務，可能需要多次查詢才能完成。

5、分片擴容

水平分片之後，一旦需要做擴容時。需要將對應的數據做一次遷移，成本代價都極高的。

6、ID生成

分庫分表後由於資料庫獨立，原有的基於資料庫自增ID將無法再使用，這個時候需要採用其他外部的ID生成方案。

一、應用層依賴類（JDBC）

這類分庫分表中間件的特點就是和應用強耦合，需要應用顯示依賴相應的jar包（以Java為例），比如知名的TDDL、當當開源的 sharding-jdbc 、蘑菇街的TSharding等。

此類中間件的基本思路就是重新實現JDBC的API，通過重新實現 DataSource 、 PrepareStatement 等操作資料庫的介面，讓應用層在 基本 不改變業務代碼的情況下透明地實現分庫分表的能力。

中間件給上層應用提供熟悉的JDBC API，內部通過 sql解析 、 sql重寫 、 sql路由 等一系列的准備工作獲取真正可執行的sql，然後底層再按照傳統的方法（比如資料庫連接池）獲取物理連接來執行sql，最後把數據 結果合並 處理成ResultSet返回給應用層。

優點

缺點

二、中間層代理類（Proxy）

這類分庫分表中間件的核心原理是在應用和資料庫的連接之間搭起一個 代理層 ，上層應用以 標準的MySQL協議 來連接代理層，然後代理層負責 轉發請求 到底層的MySQL物理實例，這種方式對應用只有一個要求，就是只要用MySQL協議來通信即可。

所以用MySQL Navicat這種純的客戶端都可以直接連接你的分布式資料庫，自然也天然 支持所有的編程語言 。

在技術實現上除了和應用層依賴類中間件基本相似外，代理類的分庫分表產品必須實現標準的MySQL協議，某種意義上講資料庫代理層轉發的就是MySQL協議請求，就像Nginx轉發的是Http協議請求。

比較有代表性的產品有開創性質的Amoeba、阿里開源的Cobar、社區發展比較好的 Mycat （基於Cobar開發）等。

優點

缺點

JDBC方案 ：無中心化架構，兼容市面上大多數關系型資料庫，適用於開發高性能的輕量級 OLTP 應用（面向前台）。

Proxy方案 ：提供靜態入口以及異構語言的支持，適用於 OLAP 應用（面向後台）以及對分片資料庫進行管理和運維的場景。

混合方案 ：在大型復雜系統中存在面向C端用戶的前台應用，也有面向企業分析的後台應用，這個時候就可以採用混合模式。

JDBC 採用無中心化架構，適用於 Java 開發的高性能的輕量級 OLTP 應用；Proxy 提供靜態入口以及異構語言的支持，適用於 OLAP 應用以及對分片資料庫進行管理和運維的場景。

ShardingSphere是一套開源的分布式資料庫中間件解決方案組成的生態圈，它由 Sharding-JDBC 、 Sharding-Proxy 和 Sharding-Sidecar （計劃中）這3款相互獨立的產品組成，他們均提供標准化的數據分片、分布式事務和資料庫治理功能，可適用於如Java同構、異構語言、容器、雲原生等各種多樣化的應用場景。

ShardingSphere提供的核心功能：

Sharding-Proxy

定位為透明化的 資料庫代理端 ，提供封裝了 資料庫二進制協議的服務端版本 ，用於完成對 異構語言的支持 。

目前已提供MySQL版本，它可以使用 任何兼容MySQL協議的訪問客戶端 (如：MySQL Command Client, MySQL Workbench, Navicat等)操作數據，對DBA更加友好。

向 應用程序完全透明 ，可直接當做MySQL使用。

適用於任何兼容MySQL協議的客戶端。

Sharding-JDBC

定位為 輕量級Java框架 ，在Java的JDBC層提供的額外服務。 它使用客戶端直連資料庫，以jar包形式提供服務，無需額外部署和依賴，可理解為 增強版的JDBC驅動，完全兼容JDBC和各種ORM框架 。

以電商SaaS系統為例，前台應用採用Sharding-JDBC，根據業務場景的差異主要分為三種方案。

分庫（用戶）

問題解析：頭部企業日活高並發高，單獨分庫避免干擾其他企業用戶，用戶數據的增長緩慢可以不分表。

拆分維度：企業ID分庫

拆分策略：頭部企業單獨庫、非頭部企業一個庫

分庫分表（訂單）

問題解析：訂單數據增長速度較快，在分庫之餘需要分表。

拆分維度：企業ID分庫、用戶ID分表

拆分策略：頭部企業單獨庫、非頭部企業一個庫，分庫之後用戶ID取模拆分表

單庫分表（附件）

問題解析：附件數據特點是並發量不大，只需要解決數據增長問題，所以單庫IO足以支撐的情況下分表即可。

拆分維度：用戶ID分表

拆分策略：用戶ID取模分表

問題一：分布式事務

分布式事務過於復雜也是分布式系統最難處理的問題，由於篇幅有限，後續會開篇專講這一塊內容。

問題二：分布式ID

問題三：跨片查詢

舉個例子，以用戶id分片之後，需要根據企業id查詢企業所有用戶信息。

sharding針對跨片查詢也是能夠支持的，本質上sharding的跨片查詢是採用同時查詢多個分片的數據，然後聚合結果返回，這個方式對資源耗費比較大，特別是對資料庫連接資源的消耗。

假設分4個資料庫，8個表，則sharding會同時發出32個SQL去查詢。一下子消耗掉了32個連接；

特別是針對單庫分表的情況要注意，假設單庫分64個表，則要消耗64個連接。如果我們部署了2個節點，這個時候兩個節點同時查詢的話，就會遇到資料庫連接數上限問題（mysql默認100連接數）

問題四：分片擴容

隨著數據增長，每個片區的數據也會達到瓶頸，這個時候需要將原有的分片數量進行增加。由於增加了片區，原先的hash規則也跟著變化，造成了需要將舊數據做遷移。

假設原先1個億的數據，hash分64個表，現在增長到50億的數據，需要擴容到128個表，一旦擴容就需要將這50億的數據做一次遷移，遷移成本是無法想像的。

問題五：一致性哈希

首先，求出每個 伺服器的hash值 ，將其配置到一個 0~2^n 的圓環上 （n通常取32）

其次，用同樣的方法求出待 存儲對象的主鍵 hash值 ，也將其配置到這個圓環上。

然後，從數據映射到的位置開始順時針查找，將數據分布到找到的第一個伺服器節點上。

一致性hash的優點在於加入和刪除節點時只會影響到在哈希環中相鄰的節點，而對其他節點沒有影響。

所以使用一致性哈希在集群擴容過程中可以減少數據的遷移。

好了，這次分享到這里，我們日常的實踐可能只會用到其中一種方案，但它不是資料庫架構的全貌，打開技術視野，才能更好地把存儲工具利用起來。

老規矩，一鍵三連，日入兩千，點贊在看，年薪百萬！

本文作者：Jensen

7年Java老兵，小米主題設計師，手機輸入法設計師，ProcessOn特邀講師。

曾涉獵航空、電信、IoT、垂直電商產品研發，現就職於某知名電商企業。

技術公眾號 【架構師修行錄】 號主，專注於分享日常架構、技術、職場干貨，Java Goals：架構師。

交個朋友，一起成長！

❷ 如何做一個優秀的架構師

《00-金融架構師 三期(大量課程)》網路網盤資源免費下載

鏈接:https://pan..com/s/1LqygEcoZLBUKp3lwLreHuA

?pwd=zxcv 提取碼:zxcv

00-金融架構師 三期(大量課程)|股權投資系列課程|20.中國十大金融高手及項目分享(翟山鷹)|19.金融項目研討會(孔憲富)|18.金融資本運營問題與迴避(孔憲富)|17.期貨與金融衍生品(翟山鷹)|16.股權私募基金(劉泓毅)|15.信託(孫金剛)|14.投資與理財(劉贏)|13.中國文化(翟山鷹)|12.財務與稅務(翟山鷹)|11.政府性融資(朱瑾)|10.融資租賃 (楊茗皓)|09.品牌與資本(孔憲富)|08.商業銀行(曾德君)

❸ 架構師都該懂的 CAP 定理

面對可能出現的網路延遲，不可預估的請求流量等情況，設計一個分布式系統，我們通常圍繞系統高可用，數據一致性的目標去規劃和實現，想要完全實現這個目標，卻並非易事。由此，分布式系統領域誕生了一個基本定理，即 CAP 定理，用於指導分布式系統的設計，從系統高可用，數據一致性，網路容錯三個角度將分布式系統的特性抽成一個分區容錯一致性模型。這樣一來，讓系統設計者只需根據業務場景特點，進行權衡設計適合業務場景的分區容錯一致性模型即可，很大程度簡化了分布式系統設計的難度。

也因此，CAP 定理是架構師所必須要掌握的內容，它影響著架構師對分布式系統的技術選型，技術決策。既然如此重要，接下來，我們就一起學習下 CAP 定理吧。

CAP 定理最初是由加州大學伯克利分校的計算機科學家埃里克·布魯爾（Eric Brewer）在 2000 年的 ACM PODC 上提出的一個猜想，也因此被叫做布魯爾定理。後來在 2002 年，麻省理工學院的賽斯·吉爾伯特（Seth Gilbert）和南希·林奇（Nancy Lynch）發表了 CAP 定理的證明，讓它成為分布式系統領域公認的一個定理。

CAP 定理指出了，在一個跨區域網路連接，共享數據的分布式系統中，一致性（Consistency），可用性（Availability）和分區容錯性（Partition Tolerance） 這三個約束屬性最終只能同時滿足二個。

下面是關於這三個屬性的簡單描述：

需要注意的是，CAP 描述了一個常規的分布式系統場景：有網路連接，且數據跨節點進行共享。如果在整個系統中，數據只有一份，並且其他節點沒有對應的副本，也不需要進行跨節點的數據共享，這樣分布式系統就不是 CAP 關心的對象了，也談不上結合 CAP 定理去設計和實施。

了解 CAP 基本概念之後，我們再來分別對 C，A，P 三個屬性進一步學習下，加深對 CAP 的理解。

這里的一致性從不同角度有著各自的描述方式，在分布式系統中表現是每個節點的數據是相同；而對於客戶端，表現是讀操作所得到的結果永遠是最新寫入的。其中需要明確的是，對於分布式系統節點來說，是可能出現某個時刻擁有不同的數據的情況：如果在某個節點執行原子性操作時，對於執行過程中的節點數據跟其他節點就並不完全一致，只有原子性操作執行完成後，節點的數據才會繼續保持同步。比如常見的事務操作，只有事務提交後，客戶端才能讀取到事務寫入的數據，失敗則回滾為舊的數據，不會出現讀取事務中間寫入數據的情況。

一致性要求了在分布式環境下的操作要就像在單機上完成的一樣，當客戶端發起寫請求時，收到寫請求的節點會及時響應，並將更新的數據同步到另一個節點，保證數據一致性。具體的工作流程，如下所示：

一致性強調了數據的強一致，這一點要求對於一些系統可以說是十分重要的。比如電商系統的庫存扣減，金融系統的轉賬扣款等場景，任何出現一致性的問題，都可能會造成很嚴重的後果。

介紹完一致性，再來看下可用性，雖然可用性概念相對簡單，但重要程度跟一致性一樣。要讓系統滿足可用性，就是要保證無論除了所有節點出現故障的情況外，系統都能返回有效的響應，允許響應給客戶端是舊的數據，但不能出現響應失敗，超時的情況。

可用性強調的是服務可用，但不保證數據的正確性。用一個簡單的例子來描述分布式系統的可用性如下：允許客戶端向節點 1 或者節點 2 發起讀操作，當其中某一個節點故障了，不管節點間數據是否一致，只要有節點服務能收到請求，就響應 X 的值，這樣就說明這兩個節點服務是滿足可用性。

在可用性的描述，還值得一提的是關於什麼算有效的響應。要返回有效的響應，不能超時，也不能出錯，結果不一定是正確的，比如返回了舊數據，但是客戶端接收到後是能進行正常業務處理的。

講完 C 和 A 之後，最後再講一下 P： 分區容錯性。由於分布式系統多個節點往往部署在多個網路環境下進行相互通信，就難免出現一些網路故障，如網路丟包，網路消息延遲，網路中斷等情況，會導致節點間的通信出現問題，數據同步操作無法完成，分區容錯性就要求了系統即使在網路分區出現的情況下，能仍繼續對客戶端提供服務。

因為分布式系統與單機不同，它涉及到了多節點間的通信和數據交互，避免不了網路問題，如果沒有分區容錯性，就意味著系統不允許出現節點間的通信出現任何錯誤，錯誤就意味著系統不可用，這在絕大數系統中無法接受的。因此對節點間的分區故障容錯是必須要考慮的，也是 CAP 定理中分區容錯性通常首先要保證的原因。

了解完 CAP 定理的一致性（C），可用性（A）和分區容錯性（P）之後，我們再來看下如何使用這個定理。CAP 定理指明了 C，A，P三個屬性無法同時滿足，而在必有網路交互和數據同步的情況下，就一定會有延遲和數據丟失的情況，對於這種情況我們又必須接受且保證系統不能掛掉。所以分區容錯性是必須要保證的，剩下的就是在一致性 （C）和可用性（A）之間做選擇了。選擇了一致性，保證數據正確性，但也意味系統可能存在不可用的情況；而選擇可用性，保證服務的高可用，但也意味數據可能出現不一致性的情況。接下來就探討下應用採用 CP 架構，AP 架構所各自的特點，以及如何根據不同的分布式場景選擇適合的架構策略。

對於 CP 架構的分布式系統來說，為了保證一致性，當出現網路分區後，如果節點 1 上數據 X 已經更新為 2，但由於節點 間數據同步的通道已經中斷，節點 1 數據無法同步到節點 2，節點 2 上的數據 X 還是 1。此時如果客戶端訪問節點 2 的數據 X，節點 2 就需要返回錯誤，提示系統發生了錯誤，直到節點間的數據保持同步。當然這樣的處理方式明顯違背了可用性的要求，因此在 CAP 定理只能滿足 CP。

如果一個分布式場景需要很強的一致性，或者能容忍系統長時間無響應但是數據要保持一致的情況，就比較適合使用 CP 架構設計對應的分布式系統。這樣的系統一旦發生網路分區會導致數據無法同步情況，就要犧牲系統的可用性，直到節點數據達到一致後再響應。在開源社區中採用 CP 架構的應用不少，比如 Redis，HBase，MongoDB，ZooKeeper，Etcd，Consul 等都是放棄了一定可用性而選擇 CP 屬性。

如果採用 AP 架構設計的分布式系統，為了保證可用性，當網路分區發生後，同樣節點 1 上數據 X 已經更新為 2，但由於節點間數據同步的通道已經中斷，節點 1 數據無法同步到節點 2，節點 2 上的數據 X 還是 1。這是客戶端訪問節點 2 獲取數據 X 時，收到是正常的響應，舊數據 X = 1，而實際上當前最新的數據 X 已經是 2 了，這里就不滿足一致性的要求了，因此在 CAP 定理只能滿足 AP。

同樣適合 AP 的場景有很多，比如一些查詢系統，電商系統的商品查詢等，大多數為了保證系統的可用性，而犧牲一定的數據一致性，這樣也保證了用戶體驗，在開源界中採用 AP 模型的典型應用有 Eurka，Cassandra。

提到了 CAP 定理，大多數人都認為無論什麼情況，分布式系統只能在 C 和 A 中選擇一個。但這里的前提是系統發生了網路分區情況，如果系統沒有發生網路分區的情況，也就是說 P 不存在的時候，我們就沒有必要放棄 C 或者 A，因此進行架構設計時也應該考慮沒有分區情況下如何保證 CA。除此之外，一個分布式系統不一定只能從 AP 與 CP 中做選擇，內部不同模塊所應對的場景也不同，完全有可能是一個模塊採用 AP 架構，另一個模塊採用 CP 架構。作為優秀的架構師，不應該受到大多數人對 CAP 定理所認識的局限，設計出符合自身業務場景的分布式系統才是重中之重。

本文主要了解和認識 CAP 定理，以及每個 C，A，P 的含義，以及 CAP 定理的應用。掌握 CAP 定理，對架構師來說非常重要。因為對於分布式系統來說，網路故障在所難免，如何在出現網路故障的時候，維持系統按照正常的行為邏輯運行就顯得尤為重要。一個合格的架構師需要是能結合實際的業務場景和具體需求，基於 CAP 定理來進行權衡和設計可用且穩定的分布式系統。

❹ 如何成為一名系統架構師

如何成為一名系統架構師

系統構架師是近幾年來在國內外迅速成長並發展良好的一個職位，它的重要性及給 IT業所帶來的影響是不言而喻的。那麼如何成為一名系統架構師呢?我們一起來學習學習網友的經驗!

前言：

來這家公司從事信息化工作已經也有三個年頭了，有必要對這三年的工作和成長以及不足之處做一個總結。在此之前，從2001年開始學習Java，那時候用Struts的開發的企業也不多，而我在的做項目的企業當時已經自己開發了Struts的快速開發平台，專門做對日軟體外包的項目，在這家公司工作，培養了我JAVA基礎知識，軟體工程的認識以及項目管理的知識。隨後博士畢業後去了一家外企做了4年的IT系統集成研究，主要用Eclipse Plugin搭建研究項目的驗證的Prototype，期間研究了SOA，SSH，LDAP，Web服務發現等技術。

剛來這家公司的時候，領導決策要將系統做重建開發。項目的具體情況是：我們擁有了成熟的業務功能，只要將老的系統的功能照搬到新的系統中，因此，對於老的系統進行了一次整理和分析，分析了合理的地方，也分析了不合理的地方，不合理的地方，希望在新系統中進行改進，但原則上，資料庫表結構不做大的改動，以免將給將來系統遷移帶來重大困難。當然，由於隨著企業的業務的發展，會有新的需求，但大部分的需求都是沒有改變的。

在項目的成員實力方面

沒有的是：

1.熟悉JAVA的開發人員。

2.J2EE項目的經驗。

有的是：

1.IT項目的開發、測試和維護經驗。

2.資料庫系統開發經驗。(其實很重要的，資料庫系統對於企業應用來說，數據也是很關鍵的，擁有這樣面的經驗，為項目的後續開發提供了不少的經驗支持)

在項目的初期階段還碰到了技術選型的問題，根據應用的特點，最終選擇了C/S三層結構，並選用標準的EJB 3.0作為中間層，採用成熟的商用中間件伺服器，這樣就解決了ORM，數據持久化等問題，這樣便確定了技術方向，這對於沒有經驗的團隊來說，也是艱難的。

上述便是我團隊的情況的簡要概況。項目總是要做的，因為領導決策了啊。先看上述兩個問題我們是如何解決的。

1.針對開發團隊沒有JAVA的開發經驗，進行培訓，由我親自操刀。培訓為期15天，從開發環境熟悉，到JAVA基礎知識，上午半天講知識，下午上機練習。

2.針對沒有J2EE的項目經驗。

整個項目就我一個人有過J2EE的項目經驗，但是我以前沒有做過J2EE項目的架構師至少沒有做過如此大型項目的，我只是做過J2EE項目的開發(B/S的，而本次項目是客戶端)並了解軟體工程、面向對象的設計、設計模式等。怎麼辦?我們是這樣解決的，請老師。專門請了老師來講架構設計知識。這還不夠，我們花錢請人做架構設計。但只是做架構設計，生成一個架構說明書後，離架構的工作還很遠，還有很長的路要走，而在合作公司做好架構設計後，他們的工作也就基本結束了。後面的`架構方面的工作，基本上是由我來做的。我說說我都做了什麼事情。

(1)按照架構說明書，將整個架構環境搭建起來。

(2)開發一套便於開發人員開發的開發框架。

(3)設計了Swing的MVC模式，並開發實現。

(4)開發了整個系統的基礎組件，為了實現架構中的復用的原則，這個很重要。

(5)負責整個系統的許可權的管理，這個很重要，跟各個模塊都有關系。

(6)負責開發的編碼規范的制定，包括JAVA的編碼的規范，同時還有質量屬性方面的編碼的規范。

(7)整個系統的異常處理、日誌、錯誤驗證等機制的設計和開發;

(8)第三方系統和工具的集成，如報表系統，瀏覽工具的集成等;

上述，只有(1)是現成的。其它的都是具體的架構方面的工作。很多人，都以為，架構師嘛，不就是高高在上的，待在象牙塔里給開發人員發號施令的人嗎?其實不然，架構師需要每天跟開發人員在一起，一起寫代碼，一起工作，一起交流。

回顧起，在搭建快速開發框架的過程中，開發人員在開發的過程中，提出了很多有意義的改進的意見，直到今時今日，我們還在改進，只有開明的架構師，才能夠設計出好的系統，好的基礎組件。當然沒有意義的，也被篩選掉的，架構師必須要有這樣的決斷力。

Swing的MVC模式就不說了，可能每個團隊對於該項設計都會有所不同。

說說如何實現組件的復用，要實現組件的復用，必須要鼓勵開發人員復用已有的組件以統一界面風格以及減少工作量。那麼，就要告訴開發人員，目前我們的系統有哪些基礎組件，他們都是怎麼樣使用或調用的。有了這些，開發人員自然就肯用了。

關於編碼規范，可能很多人覺得這是項目開發中的小事情，其實不然，某位架構大師說過，架構無小事，編碼規范的執行不力，直接影響到整個項目的代碼質量，甚至影響質量。例如，要求不要出現在循環，要釋放對象，盡量用StringBuffer等。在編碼規范的執行的難度是，不是說你有沒有規范，而是你的規范有沒有被執行。那麼如何使得你的規范被執行呢?

這就需要架構師的耐心和溝通能力了。在整個項目的開發過程中，架構師始終要保持與開發人員的溝通，苦口婆心地說，編碼規范的重要性。時間長了，開發人員養成了好的習慣，架構師也就省心了。

根據上述經驗，做個總結。

1.經驗是可以復制的，當您沒有這方面的人員時，最好請求專業或外援，並培養自己的人員，同時有吸收的學習。

2.架構師是整個團隊的技術領導，需要具備領導能力。

3.架構師需要較強的溝通能力，需要與項目的各個方面的人員進行溝通，與項目經理溝通，幫助項目經理制定合理的開發計劃;與需求分析員溝通，了解系統的關鍵需求和非功能性需求;與開發人員溝通，使得架構設計能夠被真正執行;另外還有與項目經理、物理架構負責人溝通等等。

4.架構師需要編寫代碼，這樣使自己積累更多的代碼經驗，加深理解設計模式，可以幫助自己對於整個項目更加熟悉，同時能夠回答開發人員在開發過程中出現的所有的問題，樹立個人威信。

5.架構師需要有較強的IT知識和廣博的知識面。IT的知識更新非常快，現在雲計算等的出現，必然要淘汰一部分架構師，因此，架構師要保持生命力，必須要不斷地學習。

6.架構師要懂業務知識。架構設計要滿足系統的需求。我雖然剛到公司不久，但由於之前積累了很多業務相關的知識，經過短期的學習，也掌握了業務知識。

7.不要怕做事情，我在整個系統的開發過程中，我的開發量是別人的三倍還多，但我收獲的，則也是三倍還多的經驗。

自己的不足之處：

1.有時候會著急，當規范強調了10遍，還是沒有得到很好的執行時，就開始沒有耐心了。

2.需要加強溝通能力，將自己的想法能夠推銷出去。

3.需要在更多的業務領域知識方面得到快速的增長。

下一步的目標

1.系統理論地學習架構知識，使得知識更加固化，以進一步使得架構設計更加科學和有調理;

2.通過廣泛地閱讀學習企業信息化的各個方面的知識，包括ERP，SCM，營銷管理，企業戰略，企業管理等，每年看書或閱讀文章至少100本或篇;

3.熟悉企業的業務流程，與企業不同層次的人員多多地進行交流，多學習，多溝通;

4.多交朋友，多向朋友學習與交流。

;

❺ 架構師需要學習哪些知識呢

從架構師工種角度出發，需要具備確定需求的能力，其次對技術需求進行縱向或橫向分解，達到對技術選型及成本預算、人力、運維等多角度考慮，最終確定技術進行階段並協調相關所有開發者，確保所有開發者可以按照架構規格意圖進行工作——奈學教育。

❻ 什麼是架構,架構師

架構師，是一個既需要掌控整體又需要洞悉局部瓶頸並依據具體的業務場景給出解決方案的團隊領導型人物。架構師不是一個人，他需要建立高效的體系，帶領團隊去攻城略地，在規定的時間內完成項目。

首先要搞清楚架構師主要做些什麼

1 確認需求

架構師要懂得用戶需求，理解用戶真正想要什麼，這使得架構師必須要和分析人員不斷溝通，反復確認需求規格說明書，以此來保證他精準清楚用戶需求。

項目經理劉先生在受訪時說：「架構師會與很多人溝通，例如開發人員，例如我們項目經理，有時甚至是用戶本身。架構設計的目的很明確，目的是什麼呢？挖掘用戶需求。」

2 系統分解

在架構師認可需求規格說明書後，架構師已明確用戶需求是是什麼，這時候便看架構師的分解能力了。

通過100offer入職的全棧技術架構師周先生從「縱向分解」和「橫向分解」和我們說明了系統分解是什麼——

「一般分為縱向分解和橫向分解，縱向分解是將整個系統分層，從而將整體系統分解成下一級的子系統與組件。橫向分解是在系統分解成不同的邏輯層或服務後，對邏輯層進行分塊，確定層與層之間的關系。」

3 技術選型

在系統分解後，架構師會最終形成軟體整體架構，接下來，架構師的職責是技術選型。

「前端到底用瘦客戶端還是富客戶端呢？資料庫是用MySQL還是MSSQL又或是Oracle呢？」架構師張先生在接受采訪時說，「在了解用戶需求後，分解完系統後，技術選型是非常重要的環節，提出各個方向，我再進行評估。不過，很多人都以為架構師是有決定權的，其實不是，架構師沒有拍版的權力，決定由項目經理來做。 」

架構師在技術選型階段會提供參考信息給項目經理，項目經理再從預算、進度、人力、資源等各方面情況

❼ java架構師主要是干什麼的

java架構師需要做六個方面的工作。

❽ java架構師是做什麼的

Java系統架構師是需要掌控整體並依據具體的業務場景給出解決方案的團隊領導型人物，具體工作內容如下：
1、確認需求：確定並分析客戶需求，進行項目風險評估，然後將用戶需求轉化為軟體需求，同時要補充非業務需求。

2、技術選型：需求轉化後會形成軟體的整體架構，需要根據整體架構進行技術選型。

3、系統分析：將實際項目中的概要設計、詳細設計、業務邏輯劃分、子系統與主系統的關聯、資料庫的設計等，從技術的角度完整的拆解業務，把控好技術的細節。

4、保持溝通：在整個過程中要多方面跟蹤項目進度，要和開發人員保持溝通，如果發現問題要及時解決。

總結：
1、確定並分析客戶需求，進行項目風險評估，然後將用戶需求轉化為軟體需求。
2、需要根據整體架構進行技術選型。
3、將實際項目中的概要設計、詳細設計等從技術的角度完整的拆解業務。
4、在整個過程中要多方面跟蹤項目進度，如果發現問題要及時解決。
聲明：本網頁內容旨在傳播知識，若有侵權等問題請及時與本網聯系，我們將在第一時間刪除處理。TEL:0731-84117792E-MAIL:[email protected]

❾ 怎樣根據需求進行技術選型，採用JAVA和.NET哪個好，各有什麼優勢

事OA軟體領域有7-8年了下面的文章希望對您有所幫助，同時如果你是濟寧的朋友也可以當面交流。
第一部分：oa選型的幾點建議
OA選型的幾個重要條件
第一：廠商能持續發展，只有能長期持續發展的公司才能給你提供長期的支持和升級。
第二：廠商要專注OA，一個廠商如果是什麼軟體都搞，我相信這些軟體中肯定有嘗試發展新的業務軟體在裡面，我們可不能當廠商的試驗品，由於他是多贏化發展，有可能那天就把發展不好的業務給砍掉，也有可能砍掉的就是你買的產品。
第三：產品要易用，oa產品是提供給企業全員的信息化產品，每個企業中的員工不是掌握的電腦水平都是一樣的，一定要讓大家易用，才能保證系統的成功應用。
第四：功能不要太全，有柔性就行，沒有十全十美的產品，只要他能變通實現就行。

第二部分：OA軟體的開發語言
OA軟體的開發語言很多，目前較為常見的有ASP/PHP/.Lotu Domino/.Net/JAVA 五種語言，五種語言各有特色，其最鮮明的就是——他們代表了「計算機語言發展使用簡史」。
1. ASP語言
ASP是微軟的初始WEB產品，在97年左右推向市場，是最初較早的WEB語言技術，很多小型簡單的網站都是用ASP語言開發的，由於是九十年代的產品，所以在計算機語言升級以後，其本身最大的一個問題就突顯了出來其可擴展性比較差，與現在的主流計算機語言.NET和JAVA對接都很困難，所以我們經常見到很多用ASP語言技術開發的小型網站在2003年以後面臨升級等問題時都令人頭疼，最後很多公司都採取了棄用之前的ASP語言結構的產品轉而使用最近的語言技術開發網站。
使用ASP語言腳本技術開發的產品最令軟體工程師頭疼的是ASP技術與.NET平台對接基本不太可能（筆者過去就經歷過ASP網站改造成.NET網站的事情，那經歷簡直可以用「苦難」兩個字來形容）。由於ASP的語言久遠，所以現在在新開發的系統已經使用不多。今天市場上依然能夠看到的ASP語言開發的OA軟體多是在05年以前生產的產品的基礎上改善的。

目前用ASP語言開發的產品有：金和標准版、賽飛OA等。

2. PHP
PHP語言與ASP基本上屬於同一時代的產品，但是成熟時間稍微比ASP要晚一點，PHP語言在開發上稍微比ASP復雜，其最大的優勢就是其版本就像LIUNX系統一樣是一個免費開放型的平台，開源代碼很容易就找到，這樣就解決了程序開發人員自己絞盡腦汁的去寫程序，由於是開源的，很多程序在互聯網上都可以找到，但是版權問題和安全性問題是一直困擾PHP技術的兩個難題。國內的通達OA一直有很多盜版，其實根源問題就是PHP的開源代碼性導致的（大家可以參考通達官網）。
和ASP一樣，在2000年左右，PHP成為了網站的主流開發工具，PHP與ASP相比的優勢就是跨平台性好些，但是如果面對大型結構的用戶群或者門戶網站，PHP又有一些力不從心。所以PHP技術也正在逐漸走下坡路。PHP語言目前仍有不少網站還在使用，但是主流的應用系統已經呈現正在放棄使用的趨勢，基本層面上正在淡出了開發工具的選型範圍。

目前應用PHP技術的OA產品有：通達，新思創，泛微的eOffice。

由於PHP的開源和ASP的易用性再加之其語言技術久遠，造成一種事實——現在很多高校和計算機語言職業培訓學校已經或者開始放棄了使用PHP和ASP教學，這也就決定了PHP語言技術正在淪為更新換代型的產品，對於使用者來說，就出現了未來的升級困難可能大的風險。
作為行銷策略上的吸引點，很多採用PHP和ASP技術的OA軟體多用低價的策略沖擊市場，採用這兩項技術的OA軟體實際上更多的是應用於低端產品。

3. Lotus Domino
是IBM 在96年左右流行起來的OA開發工具，優點是開發速度比較快，基於Lotus的腳本進行開發，與Lotus 的郵件系統相整合，主要用來作工作流和內部郵件的傳遞，由於Louts採用專用的文檔資料庫系統，查詢和數據統計效率就比較低下，與關系型資料庫的整合很不好。所以Lotus Notes對於僅對單一的消息和工作流系統來說是不錯的架構，但如果想做較大規模的業務整合或者業務開發會是困難重重。
使用Lotus Notes語言架構的OA產品最大的難點就是針對業務系統整合起來比較難。97年筆者曾經在北京見過IBM推廣過Louts系統，也許在國外懂louts語言的人很多，但是事實上在國內懂louts系統的人少之又少，這也就決定了louts在中國國內市場上一直都打不開局面的原因之一，由於懂louts語言的技術工程師較少，所以使用louts語言開發的軟體的產品面臨最大的困難是升級維護，物以稀為貴，louts系統工程師的支付成本也相對比較高昂。

國內應用louts語言的OA產品：合強，開思

以上三種語言技術在90年代的時候都曾經是WEB或者主流開發語言，但是隨著計算機語言技術的不斷升級換代，這三種語言技術逐漸淡出人們開發OA軟體的視線，使用這三種語言的技術工程師人員數量也呈現出階梯數量級遞減，也許到了2020年，ASP，PHP語言技術的工程師將會成為全球「稀有語言動物」，也只有到了那個時候做ASP,PHP語言的工程師拿的薪水會比主流工程師拿得多得多。

4. .Net
目前國內計算機語言的主流技術之一，有一個現象大家都可以看到——現在軟體公司的招聘廣告，從招聘廣告上我們看到現在更多的招聘對象都是JAVA和.net的技術工程師，從這個市場熱度不難看出——JAVA和.net在未來很長的一段時間里將代表開發語言的主流。
論證其是否是主流原因的方法很簡單,第一：是否有國際大廠商的支持。第二：可擴展性,可升級性,模塊化,面向對象等等優勢。產品開發出來的安全穩定性以及開發出來的可伸縮性。當然可擴展性和可升級性、模塊化這些都是沒有辦法可視化的，對於那些對OA語言感興趣的愛好者不防多看看計算機語言技術方面的書籍，其實每本書里都有介紹JAVA和.net在擴展、升級、模塊化方面的均衡優勢。第三：還有一個最為簡單的驗證方法，就是可以問問你身邊搞過研發或者懂點計算機語言技術的朋友，他們都會給你一個明確的答案。
.NET語言開發的軟體產品穩定性較高，產品可以模塊化是一個存在的事實優勢，但.NET具有很強的優勢的同時，也存在一定的劣勢，如跨平台、大數據並發。同時.Net與ASP對接時，就會導致產品的安全性變低，.NET平台的安全性會隨著ASP的安全漏洞安全為黑客或者不法分子利用進而破壞，這個也就一直困擾軟體技術工程師的一個最大的問題——.NET語言沒有辦法和ASP對接的最大一個因素之一。
目前國內基於.Net 的OA產品有：金和C6(高端版本)；領航.

5. JAVA
JAVA是1995年由SUN公司引進到我們這個世界的革命性變成語言，今天我們記住SUN這一全球性大公司的原因就是因為SUN在網路安全系統方面是最為優秀的提供商，JAVA的優秀在於與傳統的軟體比較就是：傳統的軟體往往與具體的視線環境有關，一旦環境有所變化就需要對軟體做一番改動，耗時費力，而JAVA編寫的軟體能在執行碼上兼容，只要伺服器提供JAVA解釋器，JAVA編寫的軟體就能在其上運行（更多解釋可以見清華大學出版社出版JAVA2實用教程（第二版），在這免費做做廣告o(∩_∩)o…）。
JAVA比.Net相比,可以跨平台，具有非常強的擴展性和持續性；可以在LINUX,UNIX上部署。對於一套技術先進的oA系統開發平台這是至關重要的。
目前國內基於JAVA的OA軟體：用友致遠、點擊科技。

由於JAVA和.NET語言開發的產品穩定性和安全性比較高的眾所周之的原因，所以在OA軟體的應用中使用JAVA和.NET語言開發的OA軟體銷售的價格會比ASP和PHP開發的軟體價格通常要高，但是隨著JAVA和.NET的語言技術的大規模使用，一旦JAVA和.NET開發的OA軟體進入中低端市場，PHP和ASP結構的OA軟體也將會面臨全面被取代的局面。

目前國內OA行業中還有一種「功能為王」的聲音，這部分主要是依靠ASP、PHP語言技術為主導的商家，這部分商家通常會強調「功能為王」，主觀上來看這其實並不錯，但是如果站在長期的目標來看，功能為王並不貼切，現有的功能滿足並不等於未來的功能滿足，JAVA和.Net之所以成為主流，這一點是任何技術流派不能阻止的，越老越多的軟體工程師在學習使用這兩種計算機語言，他們當然知道選擇的原因。OA選型人員應該從更加長遠的角度選擇OA產品。找到最適合自己的OA軟體產品最為重要。

第二部分:開發架構
語言是開發軟體產品的基礎，但是軟體的另外一個特徵也是非常重要的，那就是架構，事實上，搞軟體的開發的技術工程師都知道這樣一個事實——技術架構師的薪水非常高，這個在軟體開發行業裡面是不爭的事實。
開發工具的架構從基礎上決定了產品的先進程度,舉一個簡單的道理：「用不先進的底層研發出來先進的產品,是非常困難也是非常危險的。這就像我們蓋房子，房子的基礎架構是用鋼結構搭建的和用石頭和土搭建的當然不在同一個層次上，鋼結構的房屋可以在上面繼續蓋樓，而土石結構的房子一旦在其上面蓋樓就會面臨倒塌的危險，安全系數是非常低的，糾其原因就在於結構的穩定性和生命周期導致的。

所謂的開發架構就是軟體的基礎設計。
OA選型人員在撰寫軟體產品需求的時候，是否考慮到了諸如需要實現實現跨資料庫；頁面和程序分離；是否提供與外界的程序介面(WEBSEVICE)等等核心要素問題，實踐出真知啊，從人們過去的種種購買行為分析的結果表明：「客戶在購買軟體產品的時候，更多的只是關注眼前，而忽略了產品的外部介面，將來是否會發生跨數據對接等問題，看上去這些問題會離購買者很遠，其實那是一種錯誤的觀點，事實上是會時時發生，舉一個簡單的例子——由於在購買OA軟體的時候沒有考慮到會對接新的產品，所以買回來以後，企業的老闆想要對接個手機審批辦公系統，這個時候問題出現了，因為這可能會涉及到跨資料庫和外部程序介面對接介面沒辦法對接等等諸多問題，所以在選擇軟體產品的時候，更應該重點關注一下對方軟體的開發架構是什麼樣的，這裡麵包含著所謂的MVC和SOA的要領，現在互聯網上有很多這方面的資料，而且大多都是第三方的，論述的較為公正，建議大家可以上網多搜一下。.

OA軟體的發展趨勢就是安全、穩定、易用、高效、拓展性，在未來OA產品在頁面與數據分離、MVC/SOA、跨資料庫平台操作上都是應用趨勢，在這方面用友致遠和泛點擊科技具有一定優勢（畢竟用友大公司有錢可以捨得花錢來養高級的開發人員，而點擊最近由於沒有這么多錢一些開發人員陸續離職了，這也是王志東的失職。）

實際上選擇OA軟體要從以下四方面綜合考慮其架構，也建議有OA需求的朋友可以多咨詢身邊懂技術的朋友和OA廠商，懂技術的朋友也可以給出不同的意見補充。
穩定性；可維護性；可升級性；可繼承性綜合這四個方面進行考慮。

寫在最後：
購買OA產品也要考慮未來成本，OA辦公自動化軟體具有很強的粘著性,其生命周期需要使用5年甚至到10年，而軟體的架構好壞，直接決定了使用者購買的未來成本。

我給出OA軟體的購買成本的基本演算法如下，以供大家分享：
成本=購買成本+培訓成本+二次開發成本+維護成本+更換成本（淘汰成本）

建議大家在購買OA軟體產品的時候，重點要從開發語言和軟體架構上開始，不要貪圖便宜而忽略了OA軟體存在的最基礎的2個層面。同時當地的服務至關重要，因為oa具有很強的粘著度，當系統出現問題，我相信領導連半天都不能允許，說不定還可能怪在你頭上，說你怎麼不懂呀。
另外,站長團上有產品團購,便宜有保證

❿ 如何成為一個架構師

1、技術能力

技術能力，不用置疑肯定是最重要的。技術能力弱的架構不是一個好架構。所以，你需要知道所有主流技術的基本原理、應用場景，及快速解決問題的能力。所以，架構師必須要有見識，所需知識面肯定是要不斷拓展的。

你需要清楚在什麼樣的場景用什麼樣的技術比較合適，並知道可能存在什麼樣的風險。來了需求，你腦袋是空的，不知道用什麼技術這是最可怕的。

2、架構能力

這個可以表現為抽象能力、整體規劃能力、及設計能力。你需要照在業務的角度進行系統分解、技術選型、架構搭建，以及規范制定。架構出來了至少可以滿足最近的發展，或者可以很方便對現有架構進行擴容。

3、溝通能力

作為一個優秀的架構師，你需要清楚的知道客戶的需求，需要不斷和需求人員進行溝通，以達到客戶真正的目的。不論是不是架構師，任何一個職場人，提高自己的溝通表達能力無疑是不可或缺的。

系統架構師的主要功能包括：

1、系統架構師是軟體項目的總體設計師，是軟體組織新產品的開發與集成、新技術體系的構建者。

2、系統架構師是在技術上對所有重要事情做出決定的人（系統架構師在整個軟體開發過程中都起著重要作用，並隨著開發進程的推進而其職責或關注點不斷地變化）。

3、需求階段，軟體架構師負責理解和管理非功能性系統需求，比如軟體的可維護性、性能、復用性、可靠性、有效性和可測試性等。

4、設計階段，架構師負責對整個軟體架構、關鍵構件、介面的設計。協助系統分析師完成《系統概要設計說明書》。

5、編碼階段，架構師則成為程序員的顧問，並且經常性地要舉行一些技術研討會、技術培訓班等。

6、測試及實施階段，隨著軟體開始測試、集成和交付，集成和測試支持將成為軟體架構師的工作重點。