又有2周時間沒冒泡了,最近實在沒有大塊的時間來寫文章,就當找個理由。。。
一、架構的定義
任何事物都是有兩面性的,並不是說上面的這些問題,我們通過架構就要往另外一個極端去走。比如在大型的分散式系統中,不同子程序的確有必要在某些時刻選擇同類型的其它中間件。如Kafka和RabbitMQ雖都是MQ,但在特定的場景下能發揮的價值是無法相互替代的。
除此之外,架構的主要目的是為了讓大家往同一個方向,在同一個標準之上去發散擴張。一是把控硬性的下限標準,提高整體的最短版,二是提高上限水平位,也就是天花板位置,提供更大的發展空間。好比造一幢大樓,把框架結構設計好搭好,讓大家形成一個共識,什麼是承重牆不能破壞,什麼是創變空間可以自定義。在這樣的基礎下各自發展。這個看上去是個限制,但卻是做架構最重要的任務,所謂再多的文檔,再多的最佳實踐都比不上一條約束。降低複雜度、降低理解難度,是實實在在的收益。最怕的就是憑空假設帶來的過度浪費。
最後附一篇之前整理的《軟體開發中會用到的圖》的文章地址,有興趣的同學可以擴展閱讀下:https://www.cnblogs.com/Zachary-Fan/p/developdiagram.html。
上面這些完成了之後,便是選擇合適的中間件、技術框架來滿足技術層面的要求,這個的選拔主要以下面幾點來考量:
之前有聽到過一句話,概括的很精闢。好的架構必須需要貼合業務,那麼把業務+技術演變成一個數學公式來表達可以理解為:2個數字的和等於10,求如何組合能得到最大的乘積。那不是3*7,也不是4*6,而是5*5。
上面提到的這些關注點都是架構師的職責,另外特別重要的一點是,架構師必須要是個有追求的「好碼農」!!!(劃重點)。軟體架構師不像建築師,其面對的本身是一個抽象的事物,如果再脫離了實操,這基本和紙上談兵無異。所以實際工作中的難點、要點都得清楚,並且能夠給出解決方案或者方向。另外只有熟悉實操才能更準確的評估成本
? 關於作者:張帆(Zachary,個人微信號:Zachary-ZF)。堅持用心打磨每一篇高質量原創。本文首發於公眾號:「跨界架構師」(ID:Zachary_ZF)。如果你是初級程序員,想提升但不知道如何下手。又或者做程序員多年,陷入了一些瓶頸想拓寬一下視野。歡迎關注我的公眾號「跨界架構師」,回復「技術」,送你一份我長期收集和整理的思維導圖。如果你是運營,面對不斷變化的市場束手無策。又或者想了解主流的運營策略,以豐富自己的「倉庫」。歡迎關注我的公眾號「跨界架構師」,回復「運營」,送你一份我長期收集和整理的思維導圖。
? 關於作者:張帆(Zachary,個人微信號:Zachary-ZF)。堅持用心打磨每一篇高質量原創。本文首發於公眾號:「跨界架構師」(ID:Zachary_ZF)。
定期發表原創內容:架構設計丨分散式系統丨產品丨運營丨一些深度思考。