架構師，怎樣才能搞定上下游客戶？

本系列前序文章索引：

1. 程序員爲何必需要懂架構？
2. 架構究竟是什麼，你知道嗎？
3. 架構都有哪些，我該怎麼選？
4. 架構師都幹什麼，你知道嗎？
5. 練就哪些技能才勝任架構師？

架構師，在開展工做的過程當中須要對接老闆、產品、項目、開發、測試、安全和運營等各類崗位角色，他們都是架構須要關注和服務的內部客戶，他們的痛點就是架構工做的驅動因素。架構師就是要用專業技能「搞定」這些角色的需求，輸出你們都能接受的解決方案，你們好纔是真正的好。爲了達成此目的，咱們必須知道不一樣崗位的關注點。

1. 老闆產品

老闆的主要職責就是定方向、找人、找錢，他對架構設計的要求就是在給定的預算、時間範圍內研發出軟件系統，推進公司的戰略或戰術得以實現，也就是說架構方案不能過於理想，不能超出預算和截止時間。自從蘋果公司的喬布斯封神以後，如今的互聯網公司都崇尚老闆擔當首席產品官，例如騰訊馬化騰、微信張小龍、百度李彥宏等等。產品經理須要思考打造什麼樣的產品才能達成公司的戰略或戰術目的，他要綜合考慮產品是否知足功能、質量和商業等需求，知足功能需求只能達到及格線，易用性、交互體驗、性能、可靠性等質量需求可否知足纔是產品達到優秀的關鍵，以及從商業角度考慮選擇什麼時機將產品推向市場，有節奏地推進用戶和業務的不斷增加等。

任何技術都是服務於業務的，架構主要是承上啓下的做用，架構設計須要將老闆和產品的戰略戰術規劃跟開發實現銜接起來，例如：公司準備進入某個新領域，但在沒有足夠把握的狀況下先推出一款產品試試水，這個階段的架構設計就不能太超前，而是要儘可能簡單輕量，以便開發團隊可以快速將原型產品開發出來，推向市場並收集真實用戶的反饋，驗證想法。若是發現原先的想法過於紙上談兵，那麼接下來就要儘快調整方向了，這時候架構過於複雜反而不利於調整。若是通過試水驗證發現產品找準了市場切入口，用戶和業務都開始快速增加，那這時候就須要考慮作架構升級了，必須預見到後續業務發展趨勢，預留一些提早量，確保技術不會託業務發展的後腿。

2. 項目管理

咱們都知道，不論是傳統瀑布式，仍是敏捷迭代式，項目管理主要關注範圍、進度和成本鐵三角，以及知足上述三個維度約束下確保質量。那麼從服務好項目管理這個內部客戶看，架構設計必需要聽從範圍、進度、成本和質量等約束，不然項目組都解散了，再好的架構也無用武之地。

• 範圍，指需求的範圍。傳統瀑布式項目的週期較長，一般在立項之初就明確全量需求範圍了；敏捷迭代式項目是小步快跑，需求不是一次性肯定的，而是增量添加的。針對不一樣類型的項目，架構設計就須要給出相應的方案，瀑布式項目能夠搭配完整超前些的架構，而迭代式項目的架構必須是易於升級演的。
• 進度，指研發的進度。時間是項目成功的關鍵因素，時也勢也，再好再完美的產品錯過了上市的最佳時機，最終也將被丟棄到垃圾桶當中。架構設計必須考慮採用哪一種技術棧才能保障項目進度，最新的技術成熟度和社區支持不夠，或者開發團隊成員尚未足夠的知識儲備，很容易將項目拖入到無止境的延期當中。
• 成本，指研發的成本。任何項目都是考慮投入產出比的，架構方案中有沒有引入商業化的中間件產品，若是有就須要預算採購，若是採用開源產品替代，那就須要投入額外人力研究掌握。另外，技術棧難度高低也會影響人力成本，架構方案將決定團隊是否能夠並行開發等，架構設計必須在保守和激進間作好權衡。
• 質量，指產品的質量。假如如今咱們在知足進度、成本等要求的前提下交付了一款功能齊全的產品，但產品存在明顯的質量缺陷，就像銷售到用戶手上的汽車存在安全隱患，那這樣的產品不只不掙錢，還要賠錢。從架構維度看，咱們也能夠圍繞質量這個要求調整設計，讓系統變得易於測試、容災容錯性更強、彈性更好等。

 

3. 開發測試

開發測試要基於架構設計作子系統的概要設計、詳細設計、測試方案設計和測試用例編制等，從這項下游工做來看，開發測試就須要關注系統的邏輯劃分，即系統被分解成幾個子系統，每一個子系統分別承擔什麼職責，關鍵業務場景的交互流程是怎樣的，子系統之間採用哪一種交互機制和通信協議等。若是缺失這些信息的輸入，咱們開發測試的工做就會受到影響，嚴重會致使沒法交付合格的產品。

除了承擔部分設計工做以外，開發測試主要職責就是將文檔圖紙上的設計真正落地實現，這就涉及到具體技術棧的選型，也就是咱們程序員構建虛擬世界的工具。若以 Web 應用程序開發爲例，技術棧的選型主要包含如下幾個方面：

• 操做系統 OS：主要包括 Linux \ Windows \ Android \ macOS \ iOS \ watchOS \ tvOS 等，不論是服務器仍是客戶端都有多種選擇，咱們必須對它們要有概略的瞭解，而後根據需求和自身狀況選擇合適的。
• 運行時 Runtime：主要包括 Java \ C++ \ Python \ Ruby \ PHP \ C# \ JS \ C \ Perl \ Shell \ VB \ AS \ Scala \ R \ Go 等，每種編程語言都各具優點，例如：Java 生態圈很是強大，Python 特別適合人工智能領域，Go 經常使用於構建雲計算基礎設施等。
• 容器 Web Container：主要包括 Apache \ Tomcat \ Jetty \ GlassFish \ Weblogic \ WebSphere \ JBOSS \ Nginx \ IIS 等，先後端分離、靜動態資源等場景須要不一樣的容器。

若是項目壓力很大，那麼選擇熟悉的技術棧是合適的，這樣咱們就能夠聚焦在業務實現上，不用操心技術維度致使的問題。若是項目壓力適中，團隊也但願掌握一些新技術棧，以便後續可使用新技術開發新系統，那麼選擇次新的、主流的技術棧是最好的，在項目中實踐熟悉新技術，完成團隊研發能力的升級更新。

4. 運維運營

系統在發佈上線以後將會被移交給運營團隊，但運營團隊的關注點跟開發測試不一樣，他們關注系統可否穩定運行，在處理業務請求時的耗時長短、吞吐量等性能表現，當業務量爆發式增加時系統是否具有彈性伸縮能力，系統在長時間運行過程當中的穩定性、可靠性和魯棒性等。另外，任何對用戶有價值的系統上線以後都要面臨黑客、羊毛黨的攻擊，系統必需要有安全性保障，確保用戶我的信息和業務交易過程的安全。俗話說：百密必有一疏。考慮得再周全，線上仍然會發生出乎你意料的事情，系統必需要有實時檢測、提早預警和過後恢復等機制，運營的職責就是系統可以提供 7*24 不間斷的服務，不讓系統拖業務發展的後腿。

在傳統業務模式下，咱們企業的大部分軟件系統都是用於辦公自動化的，這些系統的用戶數量是相對穩定的，運營團隊只要保障這些系統穩定運行就能夠了。可是到了互聯網+時代，企業的核心繫統都是面向線上全網客戶的，併發訪問量的波峯波谷是不斷交替出現的，最大峯值流量也很難預測，這時候系統的彈性伸縮能力就顯得特別重要了，運營團隊比較關注系統是否方便擴容或縮容，是否支持跨數據中心部署，是否支持集羣的克隆部署等。這些訴求都要歸入到架構設計的驅動因素當中，確保最終輸出的架構設計方案可以知足上述要求。

收集了解上下游客戶的需求是第一步，後續咱們還須要作好平衡協調，最終輸出符合各方訴求的方案。今天先分享到這裏，接下來老兵哥還會分享如何評價架構方案。若是你對這個主題感興趣，千萬要記得先關注哦！堅持原創不易，若是你以爲有價值，麻煩動動手指點下文 「 推薦 」按鈕，讓更多小夥伴能夠看到，老兵哥會更有動力堅持分享的。另外，我後續還會分享職業規劃、應聘面試、技能提高、影響力打造等經驗，歡迎 關注 本專欄或微信公衆號 「 IT老兵哥 」！

• 軟技能-熱門文章：（首發公衆號）

1. 如何在打造影響力的路上「碼」不停？（新）
2. 2020 來了，你的 2019 曬好封存了嗎？（新）
3. 「花式」裁人套路深，你知道嗎？
4. 遭遇裁人，如何渡過心理危機？
5. 程序員「求包養」攻略揭祕

 

• 硬技能-熱門文章：

1. 如何設計出優美的Web API？（熱）
2. 程序員必須掌握的性能調優 X Y Z （熱）
3. 如何把單體式應用拆解成微服務？【上】
4. 如何把單體式應用拆解成微服務？【下】
5. 圖解 Spring：HTTP 請求的處理流程與機制【1】