架構在軟體發明的很多年前就已經存在了，但是架構的定義一直不是很明確。
由於產生分工把所有事情劃分為由不同角色的人來完成然後再進行交易，這實際上就形成了社會的架構。對於不同的行業，都可以有同樣的思考，根據自己對世界的認識，為解決某個問題，主動地、有目的地去識別問題，並進行分解、合併，解決這個問題的實踐活動。架構實際上解決的是人的問題，而概念是認識這個世界的基礎。根據架構的定義，能夠正確的認識概念，能夠發現概念背後所代表的問題，進而才能夠認識目標領域所需要解決的問題，這樣才能夠為做好架構打好基礎。做好框架首先要識別出需要解決的問題，這個能力基本上決定了架構師的水平。架構師應該問的第乙個正確的問題就是目標問題是誰的問題。找出問題的主體是做架構的首要問題，要明白是誰的問題，有什麼問題。
切分就是利益的調整，由於利益，人們認識到要主動的去切分乙個系統。構架切分的最終結果都會體現在組織構架上，只有這樣才能夠讓構架落地並推進，構架切分的結果一定是樹狀。軟體就是在硬體上編寫的程式，用來控制硬體的行為。利用軟體使每個人能夠負擔的工作越來越多，成本越愛越低。軟體工程師不堪重負，自然而然就分拆為不同的角色，形成了乙個獨特的架構體系。軟體實際上就是把現實生活模擬到計算機中，需要解決業務以及計算機問題。軟體架構的落地，需要軟體的組織架構和流程來保障，不管怎麼分拆，所達到的目標沒有任何變化，就是完成業務在計算機中的虛擬化。
要成為架構師，必須要明白解決的是別人的問題，而不是自己完成工作的問題，成本越低越號，並且這個成本是長期成本。明白如果問題不解決，究竟誰會有利益的損失？ 如果問題解決了，究竟誰會有收益，誰的收益最大？這兩個問題才能知道問題的主體 。架構師是要去平衡別人的利益，甚至去調整別人的利益，但是架構師也一定要了解一定的技術以及語言的知識。結合每個部署單元所承擔的責任，可以拆分成表達業務邏輯的**、對使用者提供訪問並儲存業務邏輯執行結果的**。技術是為了解決業務的問題而產生的，沒有業務就沒有技術存在的前提，對於架構師來說專注計算機相關的技術，忽略業務本身，可能會產生技術和業務衝突的問題，架構師應該承擔起解決業務問題的角色來，專注於business domain
和軟體本身的架構，讓技術人員致力於為業務在計算機中跑起來而努力。只有把這兩者很好的結合起來，才能更好地完成業務的目標，才會讓軟體更好地服務於大家。架構師要具備準確識別採用什麼技術的能力，考慮的主要因素也是長期的成本和收益。
這就是看完架構漫談之後對於架構的認知。
軟體系統體系架構
client server架構，即伺服器 客戶端架構。是大家熟知的軟體系統體系架構，通過將任務合理分配到client和server端，降低了系統的通訊開銷，需要安裝客戶端才可進行操作。開發容易，操作簡便。browser client架構，即瀏覽器 伺服器架構。客戶端基本上沒有專門的應用程式，應用程式...
軟體體系架構閱讀筆記十四
在服務化系統或者微服務架構中，我們如何拆分服務才是最合理的？服務拆分到什麼樣的粒度最合適？按照微服務的初衷，服務要按照業務的功能進行拆分，直到每個服務的功能和職責單一，甚至不可再拆分為止，以至於每個服務都能獨立部署，擴容和縮容方便，能夠有效地提高利用率。拆得越細，服務的耦合度越小，內聚性越好，越適合...
軟體體系架構閱讀筆記十三
3.限流模式 服務的容量和效能是有限的，在第3章中會介紹如何在架構設計過程中評估服務的最大效能和容量，然而，即使我們在設計階段考慮到了效能壓力的問題，並從設計和部署上解決了這些問題，但是業務量是隨著時間的推移而增長的，突然上量對於乙個飛速發展的平台來說是很常見的事情。針對服務突然上量，我們必須有限流...