架構漫談閱讀筆記

    原來經過閱讀《大型網站架構》的閱讀，對架構的原則和特色有了瞭解，但對於爲何要進行架構以及如何真正實現架構還並無真正的瞭解。這幾天我統統過閱讀由資深架構師王概凱執筆的系列專欄——架構漫談，讓我對什麼是架構、怎樣作好架構、軟件架構如何落地、如何寫好程序等問題有了更深入的認識。

    軟件架構實際上包括了：代碼架構，以及承載代碼運行的硬件部署架構。實際上，硬件部署架構最終仍是由代碼的架構來決定。由於代碼架構不合理，是沒法把一個運行單元分拆出多個來的，那麼硬件架構能分拆的就很是的有限，整個系統最終很難長的更大。常常會據說，重寫代碼，推翻原有架構，從新設計等等說法，來講明架構的進化。這實際上就是當初爲了完成任務，沒有充分思考所帶來的後果。這也並非架構進化的事情，而是我的對問題領域的逐漸深刻理解的過程。

    認識架構是理解架構的基礎，架構的實質是解決人的問題。在軟件架構階段，有效的去認識概念，明白概念背後的含義，以及利用對概念的理解，快速的進行學習相當重要。找到真正的問題，這個能力決定了架構師的水平。找出問題的主體，是作架構的首要問題。如何正確的認識問題，這須要問兩個問題： (1)這是誰的問題？ (2)有什麼問題？當獲得的回答是支支吾吾的時候，咱們就知道正確的方向在哪兒，以及須要作哪些事了。可以清晰的定義問題，是解決問題的第一步。

    在認識問題後是如何解決問題。軟件開發的過程通常都是團隊合做，這就涉及到了利益的切分。架構的切分的導火索是人、時間的負載過重。每一個人的能力有限，或者單我的來作的話，時間太長。架構的切分實際就是對系統的利益相關人的利益進行切分或合併，使得每一個系統的利益相關人的權責是對等的，每一個系統的利益相關人能夠爲本身的利益負責。架構切分的最終結果都會體如今組織架構上，只有這樣纔可以讓架構落地並推動。架構切分的結果必定是一個樹狀，這也是爲何會產生分層。層數越多溝通越多，效率越低，分層要越少越好。儘量變成一顆平衡樹，才能讓整個系統的效率最大化。

    咱們作過軟件，但什麼是軟件這個並不能很好的給出解釋。。在硬件上編寫出的程序，就是軟件，是用來控制硬件的行爲的。在有軟件以後咱們將生活的事情虛擬到計算機。其實軟件架構師的出現與軟件的的發展着實類似，從開始寫軟件到切分，演變成不一樣的架構這個演變的動力就是提升人的利益，下降成本。

軟件架構師的本質是發現問題。軟件架構實際上包括了代碼架構以及重載代碼運行的硬件部署架構。軟件架構是否真的須要這取決於任務的大小，若一我的就能夠很好的開發何須架構。當訪問的流量愈來愈大，機器就會愈來愈多，代碼的部署單元就會拆分的愈來愈多。這是就須要軟件架構了，這也是軟件架構的意義所在，解決多人開發的問題。

    軟件架構過程能夠明確地拆分爲兩個不一樣的責任：其一，表達業務邏輯的代碼，不少人把這部分叫作Domain Logic,或者叫Domain Model。這部分實際是來源於生活的，必須保持和現實生活中的切分一致，並不是人爲的抽象而成。其二，對用戶提供訪問並保存業務邏輯運行結果的代碼。計算機的狀態保存有一個缺陷，本機保留業務運行結果有很大的問題，通常都在外存儲設備上保存，也便於擴展。衆所周知，service的代碼是最複雜的，須要服務於三方，爲了把這三方的變化對service的影響降到最低，對於service進一步的拆分爲三個部分，他們分別是Service、Glue Code、Business,讓每個部分都可以獨立的變化，這樣這三方的變化就不會產生連鎖響應，下降成本。這就是軟件架構的本質思想，因爲我還爲進行過項目的架構的使用，對架構如何在項目中實現還不是很明白。

    該怎麼處理業務、技術還有架構的關係也是一門學問，技術老是在人類解決對業務的要求不斷提升的狀況下產生，目的也是爲了獲取更大更好的利益。因此，準確識別採用什麼技術的能力，也是架構師所要具有的能力之一。經過對這本書的閱讀，從總體的角度對軟件架構有深層側的理解，這是在進一步進行實際項目的開發中應具備很重要能力。