這些感悟并非來自于具體的技術實現，而是關于我在架構設計和實施過程中所體會到的一些軟性經驗和領悟。我希望通過這些分享，能夠激發大家對于架構設計和技術實踐的思考，幫助大家更好地理解和應用架構原則和方法。
一、“提出問題”難于“解決問題”
在我看來，我最近的一個重要感悟是：提出問題要比解決問題更具挑戰性。作為一個工程師，我通常習慣于解決問題，因為這是我們的工作之一。但是，我意識到我很少主動提出問題，尤其是從用戶的角度出發去提出問題或需求。我發現，這種不主動提出問題的傾向可能導致團隊內部的溝通障礙，特別是與產品經理等其他團隊成員的交流。
有時候我們會抱怨產品經理不懂技術，提出的需求不夠專業。但是，我開始思考，作為工程師，我是否應該更加積極地從用戶的角度出發，去了解用戶真正的困惑，并提出合理的需求來解決它們。或者，我是否可以親身體驗用戶的場景，然后提出全新的問題并解決它們。
我認為，我們不僅僅應該是解決問題的人，還應該是提出問題的人，主動去思考如何能夠讓業務更加先進。盡管設計架構、編寫代碼解決問題是一項很棒的工作，但是當我嘗試主動提出問題和改進用戶需求時，我發現這其實是一項更加困難的任務。我覺得這種思維轉變，對于我個人的職業發展和團隊的成功都是非常重要的。
二、決定“不要什么”比“要做什么”更難
在我看來，我最近的第二個重要感悟是：決定“不要什么”比“要做什么”更具挑戰性。或許這是因為人性的本質是貪婪的，所以在項目或架構設計中，我們常常傾向于盡可能包含更多功能和需求，特別是對于非功能性需求更是如此。
當我們審查一個架構設計說明書時，往往會看到對高可用性、高性能、高擴展性、高可維護性等需求的強調，幾乎所有的架構設計都會列出這些非功能性需求。這些需求似乎成了一個共識的列表，認為所有的架構都必須滿足這些需求。當然，功能性需求更是不勝枚舉，產品經理會不斷地添加。
然而，回過頭來仔細思考，什么是架構？實際上，在很多層面上，架構是一種權衡和平衡的結果。作為一個架構師，你應該是那個能夠明確說出“不要”的人。在現實中，很多東西是無法兼得的。比如，是盡早發布產品，還是等到所有功能都完善再發布；又比如，在一致性和性能之間需要取舍，我們是選擇強一致性，還是犧牲一致性以換取更高的性能等。CAP 原則就是這樣一個關于權衡的準則。
因此，作為架構師，我強烈建議大家在架構設計的初期就確定一些原則。例如，數據一致性優先級最高，或者盡早發布基礎功能版本優于延遲發布完善功能產品等。當面臨沖突時，我們可以利用這些原則進行取舍和決策。
三、非功能性需求決定架構
在我看來，我最近的第三個重要感悟是：非功能性需求決定架構。在很多人眼中，做架構的第一步是收集各種功能性需求，因為最終的產品是為用戶服務的。
然而，事實并非如此。一個優秀的架構實際上是由非功能性需求所驅動，而不是由功能性需求所驅動。你會發現，對于一個功能，可以有很多種不同的架構方案來實現，但是你為什么選擇某個方案，其實是由非功能性需求來決定的。
大家都非常清楚什么是非功能性需求，包括性能、伸縮性、可擴展性、可維護性等，甚至還包括團隊的結構、技術水平、發布周期要求等等。通過這些需求來篩選可用的方案，最終找到一個合適的架構。
因此，非功能性需求在架構設計中扮演著至關重要的角色，可以說是決定性因素之一。設計完架構后，如果缺少某個功能性需求，我們很容易意識到并且可以進行補充，它不會對架構產生根本性的影響。但如果我們忽略了某個非功能性需求，那么在未來可能會導致嚴重的問題，甚至需要重寫架構。例如，如果架構中的數據一致性問題無法解決，或者在設計階段沒有充分考慮性能問題，那么所有的功能性實現都會變得毫無意義。這基本上就是重構，甚至可以說不應該叫重構，而是應該叫重新創建或者重寫，因為你需要徹底重新設計整個架構。
實際上在架構領域，大家對這點也是有共識的。比如下圖中這個 Micro-Kernel 的架構模式來自《面向模式的軟件架構》的第一卷，它一大特點就是有比較好的可擴展性，同時通過 Plugin 之間的隔離，能夠提高系統的可用性。
“簡單"并不容易
在我看來，我最近的第四個重要感悟是：“簡單”并不容易。許多架構師都會強調保持簡單，但很多時候我們會混淆簡單和容易。簡單是指簡潔、清晰，而容易是指易于實現、理解或操作。我們應該努力保持簡潔，而不是追求輕松的實現。
正如喬布斯所說，簡單有時比復雜更難，因為它需要對問題、事物的深入研究，才能找到真正簡潔的解決方案。簡單實際上是一種巧妙的設計和思考。
舉例來說，布隆過濾器就是一個簡單而高效的重復數據過濾算法，它巧妙地解決了一個問題。如果想要使某件事情變得簡單，就需要進行大量深入的工作。例如，簡化架構很大程度上取決于我們對技術、開發過程以及不同業務場景的深入理解，而不僅僅是架構本身的設計容易與否。
因此，保持簡單并不容易，它需要我們深入理解問題的本質，并找到最優雅、最有效的解決方案。
舉個例子，我們來回顧一下軟件生命周期中各個階段的成本消耗占比。
可以看到，在整個軟件生命周期中，成本消耗最高的并不是設計、編碼這些階段，而是維護階段。也就是說，如果你讓維護變得簡單，這會是最有性價比的。
五、永遠不要停止編碼
在我看來，我最近的第五個重要感悟是：永遠不要停止編碼。這一點非常重要，特別是對于一個架構師來說，要牢記自己始終是一名程序員。作為架構師，我們可能設計了一個高層次的架構，但實際上，代碼才是軟件的最終實現形式。每個程序員在架構落地的過程中的實現，都可能影響最終的架構呈現。
此外，如果你停止編碼，最大的影響不是技術上的滯后或代碼編寫速度變慢，而是你可能會逐漸失去對編程的敬畏之心，忘記作為程序員的體驗，特別是編碼過程中的那些挑戰與痛苦。你可能會陷入一些不切實際的幻想，做出一些不切實際的設計，這才是最大的問題。
我們都熟悉 JAVA 的創始人 James Gosling，在亞馬遜擔任杰出工程師的職位，相當于高級副總裁，但他依然堅持編碼。他每年編寫的代碼量是驚人的，常常超過 10 萬行。這個事實告訴我們，無論職位有多高，作為一個技術人員，始終保持對編碼的熱愛和投入是至關重要的。
六、風險優先
在我看來，我最近的第六個重要感悟是：風險優先。
讓我們先思考一個問題：為什么要進行架構設計？在我看來，架構設計的主要目的是轉化、降低、甚至避免整個開發過程中的風險。作為架構師，我們的一個主要責任就是在項目的早期階段識別出系統可能存在的風險，并通過我們的設計來轉化、消除這些風險。
我們經常提到的原型方法或者架構切片的快速迭代方式，實際上也是在早期盡量測試風險，評估我們的架構是否能夠解決相關問題，特別是那些非功能性需求的實現風險。這些風險往往不像功能性需求那樣容易在項目初期被發現，但是修正它們的成本通常比修正功能性需求要大得多，甚至可能導致整個項目的失敗。
比如敏捷開發，很多人認為敏捷開發只是更快地開發出一個產品，然后快速地將其交付到市場上，但這只是敏捷的一部分。另一個很重要的方面是，如果一個項目注定要失敗，那么就要盡早地讓它失敗，絕對不能將風險留到最后。這也是敏捷方法的一種體現。
在這里，我想推薦一本書《Just Enough Software Architecture（恰如其分的軟件架構）》。這是一本非常流行的架構書籍，強調了架構設計的目的是為了化解軟件實現中的風險。如果項目中的所有風險都可以通過未來的重構來解決，那么你根本就不需要進行架構設計，直接等待重構即可。這也是我非常贊同的觀點：風險優先。
從“問題”開始，而不是“技術”
我最近的第七個重要感悟是：從“問題”開始，而不是“技術”。
作為技術人員，我們往往會很樂意學習新技術，并且一旦掌握了這些技術，就會有強烈的欲望去應用它們。有時候我們甚至會感覺自己被某個技術所“上身”，迫不及待地想要將其應用到工作中，而忽略了當前手頭上的問題是否適合用這個技術來解決。或許你也有類似的經歷。
冷靜下來想想，我們每個人都明白，應該從實際需求、用戶問題出發，而不是一味地從技術角度考慮。然而，在實際工作中，我們常常不自覺地忽略了這一點。就像拿著一把錘子，看到什么都想當作釘子來敲。
然而，這種做法可能會帶來很大的害處。讓我來分享一個故事，來自我之前工作過的一個團隊。
在那個團隊中，有一位工程師維護著一個簡單的服務，使用 MySQL 作為數據存儲。后來，他對當時新出的 DynamoDB 產生了興趣，并學習了相關知識。結果發生了以下情況：他決定使用 DynamoDB 替換 MySQL，但這卻成為了一個噩夢的開始。很快就發現 DynamoDB 并不能很好地支持事務特性，而且性能極差的客戶端類庫導致了性能問題，效率大大降低。
于是，他又嘗試使用最終一致性技術，采用消息隊列來實現。但隨之而來的是，實現相同功能的復雜性大大增加，維護成本也由一個人變成了整個團隊。
這個故事告訴我們，我們對技術的熱情有時會讓事情變得更加復雜，甚至會帶來額外的煩惱。我們應該始終從問題出發，而不是被技術所驅動。
八、過度繁忙使你落后
我最近的第八個重要感悟是：過度繁忙使你落后。
對于IT人員來說，忙碌已經成為了一種習慣，加班似乎也成了公司高效的標志，“996”甚至變成了一種常態。但是我們有時候需要反思一下，有多久沒有在業余時間看與技術相關的書了？我曾經在公司里問過這個問題，百分之百的人都告訴我，下班后已經很晚了，回到家基本上沒有時間再看書，刷一下手機，就可以直接睡覺了。這是一個非常值得我們去思考的問題。
作為技術人員，如果你不更新你的知識，或者繁忙讓你沒有時間更新知識，那會有什么樣的結果呢？讓我分享一個有趣的現象，我遇到過不少程序員，有些是之前的同事，有些是朋友。他們換了一份新工作，一開始進入那家公司時會說，“這個公司我不是特別看好，我了解一下它的技術，就準備跳槽了。”可是過了兩三年，我再問他們，“為什么還在這里，還沒跳槽？”結果他們告訴我，“我覺得現在的招聘形勢不太好，不太好找新的機會。”幾年下來，他們對公司越來越“忠誠”了。實際上，在一個公司忙碌工作幾年，沒有留出時間學習，導致他們失去了跳槽的能力和勇氣。當他們想要重新回到市場時，卻發現自己已經落伍了，技術已經過時了，甚至已經被淘汰了。
在這個高速發展的時代，如果因為過度忙碌，導致你沒有時間學習和更新自己的知識，那必然會讓你落后。即使你不跳槽，呆在同一家公司里，公司的業務不斷發展，數據量會越來越大，用戶需求也會越來越復雜。如果你長期不更新知識，掌握的技能沒有發生變化，你會覺得越來越難以應付，最終只能通過不斷地加班來應對。
另外，還有一種可能是，你不更新知識，不深入思考，那么很大概率，你所創造的技術和業務喪失了領先性，沒有領先優勢，只能被動緊緊跟隨競爭對手。而緊緊跟隨就意味著你只能加班，這將導致更多的忙碌，更少的時間用來學習和提升自己的技能。這實際上是一個惡性循環，你花越多的時間去忙碌，就越沒有時間去學習，去提高自己的工作技能，最終只能靠加班來追趕，結果就更加忙碌，更加沒有時間學習，最終你將陷入一個無法自拔的惡性循環中。
當我在某個領域工作了一段時間后，比如三五年之后，我會逐漸變得對該領域的業務越來越熟悉，解決問題也會變得更加順手。但與此同時，我也會意識到能夠學習到的新知識和技能會逐漸減少。有些人可能會建議我離開這個舒適區，嘗試去另一個領域，以激發學習新知識的動力。但我覺得并不需要這么做。
我認為，即使留在原來的領域，我也可以通過一些方法來持續學習和成長。我可以有意識地擺脫舒適感，擠出時間來重新學習，然后嘗試以不同的方式解決問題。即使在相同的領域中，我也可以探索新的方法和技術，從而提升自己的能力。
通過持續學習和不斷探索，我可以在工作中保持活力，并不斷地提升自己的競爭力。這種積極的學習態度和探索精神對于我的職業發展是非常重要的，它能夠讓我保持在一個不斷成長的狀態中。
作者丨 greencoatman
來源丨公眾號：二進制跳動（ID：gh_6fead375a876）
