一、生命週期
一個事物一旦出生，就必然會長大，變異，一旦長大，就面臨著衰老，接下來就是消亡了，這個過程就稱為一個事件的生命週期，實際上就是指的生滅
每一個活動都是一個生命週期，生命週期中包含生命週期，一個生命週期消亡會產生另一個生命週期
生命週期裡包含有各種活動，這些活動是推進這個生命週期的必要因素，並且這些活動之間有時間上的推進關係
生命週期總是有一個主體，因此更多的是明確指出某某的生命週期，所以識別出生命週期的主體是至關重要的事情
一個生命週期裡面的活動可以進行拆分，拆分的原則就是形成若干個新的生命週期，每個新的生命週期都有自己的主體，拆分之後主體不變的子生命週期，稱為核心生命週期，主體改變的稱為非核心生命週期，尋找核心生命週期的過程實際上也就是一個發現內聚的過程
拆分出來的生命週期各自都有自己的邊界，不會影響到其他的生命週期，因為各自的變化都在自己的生命週期內確定。每個主體的生命週期活動的變化都累積在該主體本身，這就是內聚。要做到內聚，必然要先確定生命週期的主體和生命週期本身
空間上連續的限制可以通過生命週期拆分來打破，形成空間上並行和時間上串行執行的狀況
非核心生命週期的管理和執行、核心生命週期的管理和執行可以在時間和空間上並行，但執行仍然還是要依照拆分之前的大生命週期的順序
從生命週期內部來看，生命週期的每個階段是隨著時間的推進而發生變化的，因此呈現出來的是一個按時間順序發展的狀況，當啟動一個核心子生命週期的時候，必須把樹上該節點的所有父生命週期啟動才可以，也就是所謂的業務流程，因為大生命週期本身內部活動還是按照時間順序連續發生的
非核心子生命週期處於一種服務的狀態，要按需給出結果，執行時間足夠短的可以在請求的時候實時執行，太長的則需要預先執行好，需要時直接給出結果。非核心子生命週期拆分出來成為服務後，這個服務不再僅僅給一個人用，而變成了所有人都能夠共享，不在侷限於原有的大生命週期，而大核心生命週期則變得更加精簡，可以專注於自己的核心生命週期活動
二、時間
生命週期的變化體現的就是時間，而時間只不過是人們對事物變化的一個度量
在同樣的時間內創造出更多的產出，相當於把自己的生命延長了，儘量做自己擅長的事情 ，以期獲得最大的產出
三、為什麼會產生架構
除了那些別人無法替代必須要由自己來完成的核心生命週期活動外，把其他的生命週期活動並行起來，在同樣多的時間內做更多的事情，也相當於延長了自己的生命
原來需要一個人完成所有事情，生命週期被細分為很多小的非核心生命週期，這些小的非核心生命週期，就可以由另外一個人來負責，在空間上和時間上都得以並行，原來那個人只需要獲得另一個人的結果就可以了
四、什麼是架構
架構產生的動力：必須由人執行的工作、每個人的時間有限、對目標系統有更高的要求、目標系統的複雜性使得單個人完成這個系統時會受限於時間
架構的思考來源於對生命週期的識別，以及對生命週期的拆分，如果沒有生命週期拆分的思考，就不能算架構
建築架構按照人類生命週期的需求，對地球上的空間進行切分，並通過門窗、地基等技術，保持和地球以及空間的有機的溝通
什麼是架構：
根據要解決的人類的問題，對目標系統的邊界進行界定
圍繞目標系統核心生命週期進行切分，切分的原則是要讓非核心生命週期獨立出來，便於不同的角色並行地開展工作
對這些切分出來的部分，確立各自的生命週期及其主體，以及負責的角色
在這些拆分出來的非核心生命週期和核心生命週期之間設立溝通機制，使得這些非核心生命週期能夠圍繞核心生命週期，通過樹狀架構組裝起來成為一個整體，共同為核心生命週期做出貢獻
人類架構實際上就是指人們根據自己對世界的認識，為解決某個問題，主動地、有目的地去識別問題，並根據核心生命週期進行分解、合併，以解決這個問題的實踐活動
人類的架構總是在人類的業務遇到瓶頸的過程中產生，在瓶頸的解決中應用，在業務消亡時，也跟著消亡
架構的生命週期被拆分為兩個子生命週期：
架構設計生命週期，研究業務本身的生命週期，根據問題發現瓶頸，進行架構拆分，把非核心生命週期拆分出來
架構實施生命週期（核心），為了把架構的拆分落實到組織架構上，讓每一個人能夠按照架構的職責拆分，並行工作，執行各自的生命週期
五、架構和樹
主幹就相當於核心生命週期，決定樹的生死。枝葉是非核心生命週期
樹狀結構特別適合於增長，圍繞著核心生命週期，把非核心生命週期剝離，也可以使得核心生命週期更加精簡、輕量化，更容易應對周圍環境的變化，樹幹也更容易長得壯實
分層實際上就是架構樹拆分的結果，跨層訪問就形成了圖
不是樹狀結構，嚴格來說不算架構，因為並不能保證權責對等，業務會受其阻礙不能順利長大，甚至導致業務的失敗
架構是順應業務生命週期規律的一種拆分，這個拆分始終是圍繞著業務的核心生命週期的，結果也只有一種，就是一顆樹，只有權責對待才能夠保證參與人能從其自身的工作中獲利，才能夠保障參與人能夠持續不斷地推進業務的生命週期
六、概念
人類架構實際上解決的是人的問題，而概念是人互相溝通並認識這個世界的基礎，對概念的認識因而變得非常的重要
名相：名字指代的看到的東西就是相，就是事物的相狀。相實際上代表的是影像，以及這個影像背後所產生的作用，是人對這個作用的認識，並不是具體的某個東西。而名是用來標識這個影像和作用，用來溝通交流的
每個概念實際上所解決的，還是人遇到某個特定的問題，把解決問題的解決方案給定了一個名字，這個名字就是對應的某個特定的概念
要做好架構首先必須具備的能力就是要能夠正確地認識概念，能夠發現概念背後所代表的問題，找出核心生命週期，進而才能夠認識目標領域所需要解決的問題
做架構的時候，很多時候都是在一個新的領域解決問題，必須要快速進入並掌握這個領域，才能夠真正的解決問題
七、什麼是抽象
抽象是“abstract”，是“抽取、摘要”的意思
每個事物本身都有其獨特的地方，我們稱為事物的個性，要定義一個事物只能用這個事物獨特的地方，也就是它的個性，而不是共性，但抽象恰恰主要關注在共性上，要找出事物的個性，就必須要深入分析和理解 這個事物的核心生命週期，核心生物週期明確了，事物的個性也就明確了
不能用抽象來定義一個事物，抽象實際上是一個分類的過程，抽取出事物中抽取人所關心的一些特徵，並且不同的人抽取的側重點是不一樣的，甚至完全不同
做架構需要具備識別個性的能力，也就是要有發現獨特問題的能力，必須親自體驗業務，感受業務，才可能真正認識業務的個性，真正認識業務所面臨的問題，在理解業務個性的基礎上，才能夠談共性，否則這個抽象就像是無根之木，侷限於個人的主觀認識，是很難長大的
八、識別問題
識別問題的能力基本上就決定了架構師的水平
當我們去解決一個問題的時候，一定要克服對時間的焦慮，耐心地先把問題搞清楚，只有真正敢投入思考“是誰的問題”，關心“真正的問題是什麼”的工程師，才有可能成為真正的架構師
識別問題的一個最重要的前提就是要搞清楚：是誰的問題，也就是要先明確問題的主體是誰。主體搞清楚了，問題的邊界也跟著確定了，再去討論問題才有意義。
當我們處理問題的時候，如果發現自己正在致力於把自己的工作完成，就要馬上警惕起來，因為這樣下去會演變成沒有主人翁精神（Ownership）的工作態度。在面對概念的時候，也會不求甚解，最終會導致無法真正的正解概念
架構師要解決的基本問題，都是別人的問題，別人的問題解決了，自己的問題才能解決掉：任何找上架構師的問題，絕對都不是真正的問題，發現問題永遠比解決問題更加重要
明白了問題的主體，人們才可能真正地認識問題是什麼。因為問題的主體是問題的隱含邊界，邊界不確定下來，問題就是不確定的。常用的方式就是直接面對主體進行訪談，深入到主體的工作生活當中，體驗並感受這些問題，識別關鍵生命週期，進而識別出非關鍵生命週期
從問題暴露的點，一點點地去溯源查找，一定會找出來究竟是誰的問題，以及是誰的問題
要正正確的認識問題，需要問兩個問題：這是誰的問題、有什麼問題
九、切分的原則
很多時候問題的產生都是因為溝通的誤解，或者主觀上有過多不必要的利益訴求導致的
架構師要非常清楚，所有的切分調整，都對相關人的利益進行調整，分工背後的動力來自於每個人尋求自己的利益最大化的衝動
所謂利益，其實就是保障自身的生命週期活動推進的質量。人們需要放棄一些自己不擅長的事情 ，分工的結果讓大家都能夠得到更多。人們對自己利益的渴望也是推動社會物質發展的原動力
如何提供更好更有質量的服務給這個社會，提供的服務更好更多，就能夠換取更多更好的生活必需品，這也是人們在人類社會生存、立足、做人的基本道理和原則：先要付出才能夠有收穫
當人們認識到要主動地去切分一個系統的時候，就不能忘掉利益這個原動力，所有的切分決策都不能夠違背這一點
利益相關人負載太重是導致切分的原因，權責不對等是切分不合理而導致的新問題，對於負載太重的問題，本質都是時間上的負載過重，有限的時間內無法得到期望的產出。只有把該利益相關人在時間上連續的動作，切分成時間或空間上可以並行的動作，在時間或空間上橫向擴展，讓更多的人並行工作來提升產出
架構切分的原則：
被切分的生命週期，如果必須要生命週期的主體在連續時間內持續執行，而且不能夠被打斷並更換生命週期主體的話，就不能切分出去
每個生命週期的負責人，對所有負責生命週期的權力和義務必須是對等的，權責不對等最終會導致架構無法落地，甚至導致業務失敗
切分出來的生命週期，不應該超出一個自然人的負載
切分是內部活動，內部無論怎麼切，對整個系統的外部都應該是透明的，如果因為切分導致整個系統解決的問題發生了變化 ，那麼這個變化就不屬於架構 的活動
所有的架構拆分都應該形成樹狀的結果，不應該變成有向釁，更不應該是無向圖
權責不對等的情況一旦出現 ，架構師必須馬上意識到，這個問題持續時間越長，企業的動作效率就會受到越大的影響，對利益相關人的利益是非常不利的，同樣對於企業的利益也是不利的
樹的層次越深，溝通損失就越大，效率也就越低，平衡樹的深度可以做到比較均衡
架構的切分過程就是建模的過程，核心生命週期模型把所有的模型通過樹組織起來，形成一個新的模型
架構的輸出實際上就是一個系統的模型，一棵以業務生命週期為樹幹的樹，要識別出有多少個相關方，每個相關方需要承擔哪些權力和義務，不同的相關方是以什麼方式組合起來完成整個系統
在進行架構切分的時候，往往也是組織在長大的時候
總結：
架構的拆分的導火索是人的負載太重，也就是時間不夠
架構的切分實際就是對利益相關人的利益進行切分或合併，使得每個利益相關人的權責對待，每個利益相關人可以為自己的利益負責
架構切分的最終結果都會體現在組織架構上，只有這樣才能讓架構落地並推進
架構切分的結果一定是一個樹狀，這也是為什麼會產生分層 ，儘可能變成一棵平衡樹，才能讓整個系統的效率最大化
十、架構與流程
流程就是多個角色為了把一件事情做好，按時間順序協作並完成的整個過程，包含了很多的活動，很多的判斷，很多的分支，本質上也是一個生命週期
流程關注的是多個人如何把同一個目標完成，是描述整個事物發展各種可能性的樹
對業務流程梳理是非常重要的事，往往就代表了業務的核心。不要被樹枝、樹葉迷惑，樹幹樹根才是真正的核心
流程的推動都是和人相關的，流程實際上串聯出來的是不同角色協作的過程
生命週期拆分之後，就意味著權力的下放，因此往往會產生審批的流程
核心是業務生命週期，業務為了長大，發生了架構拆分，形成了一顆樹，而流程則把拆分之後的業務進行組合，通過遍歷樹，重新形成了業務生命週期整體
十一、什麼是架構師
架構的目的就是為了增長
架構師會把需要增長的業務瞭解清楚，挖掘出核心生命週期，並確定核心生命週期的主體，就是要發現問題的主體，並確定核心問題，還需要對業務核心生命週期進行分析，剝離出非核心生命週期，並根據當前人員的狀況，合理地分配非核心生命週期的權責
還需要更進一步，那就是根據對不同的生命週期的運營情況，對未來的增長做一定的預判，提前做好規劃，做相應人員、技術的儲備——這就是戰略架構
任何一個人，只要他在思考如何做得更好，如何做得更多，必然會導致他去思考核心生命週期，那麼他已經在做架構的思考了
做架構師，必須要具備調動資源的能力，只能具備權力落地的人才能叫架構師，架構師本質上就是權力的代名詞。
架構師要把增長放在自己的第一考慮要素，把識別核心生命週期及其主體作為第一思考，這樣才能確保權力的合理分配，保證增長的效率。必須深入到業務的核心領域，親身體會業務的痛點，業務的個性，這樣才能夠挖掘出業務的核心生命週期，才能夠做好拆分
十二、什麼是軟件
軟件實際上是人類有意無意地在計算機上模仿自己這種原始動機的體現，讓人們能夠節省大量的工作時間，有更充足的時間去關注並推進自身的核心生命週期
邱奇—圖靈論題：一切直覺上能靠可計算的函數都可用圖靈機計算，反之亦然
成本是我們為什麼採用計算機和軟件的主要動力，它可以幫助人們節省大量的人員培訓，減少僱員的數目，使得人們脫離重複的勞動
我們常說軟件或技術（軟件當然也是一種技術）是業務的使能者（Enabler），實際就是把業務的成本從原來很高降到了很低的程度而已，並不是有了什麼新的業務。另外，軟件也不是降低業務成本的唯一方式
軟件的出現讓機器的生命週期產生了分工，形成了硬件生產生命週期和軟件生產生命週期兩種形式
軟件的出現，讓只有“身體”的機器具備了“大腦”。機器通過更新“大腦”中軟件的方式不斷地學習，變成了一個“活著”的虛擬“人”。虛擬人的出現，導致人類社會也開始軟件化、互聯網化
軟件模擬出了一個虛擬世界，打破了物理時空的限制，極大地提高了生產力，從而完成更多的生命週期
十三、軟件的生命週期
一個軟件，因為某個業務虛擬化的需要而產生；後續不斷地更新、修改，推動軟件逐漸變異、長大；當該軟件不再被需要（因業務的變化），或有更多好的軟件來替代時，該軟件就會被廢棄，完成使命而消亡
軟件的整個生命週期也會發生切分，從而形成兩個子生命週期：軟件開發生命週期和軟件運行生命週期
軟件運行生命週期是核心生命週期，因為軟件運行生命週期的主體和大的生命週期一致。從另一個角度來說，人們真正需要的是軟件啟動後為我們帶來的服務，也就是說軟件運行生命週期才是人們真正需要軟件的地方
非核心生命週期：
軟件的開發生命週期：產生可運行的軟件，內部還會發生切分，如需求生命週期、代碼開發生命週期、測試生命週期等
軟件的運行生命週期：核心生命週期，又包含軟件的訪問生命週期、軟件的功能生命週期、軟件的監控生命週期
ROI（Return On Investment）在軟件開發組織的時候，是否需要創建一個軟件，要由大家一起來討論，認證其必要性，確定代價和所獲得價值的對比
從軟件運行生命週期角度來說，一個可運行的獨立部署單元才算是一個軟件
從決定開始生產一個軟件，到軟件真正地運行起來，會經歷一段時間的代碼積累，這個過程就是軟件開發的生命週期
軟件開發過程中所有活動都是為了幫助軟件工程師能夠把代碼寫對，把業務虛擬出來，工程師必須要理解日常生活中是怎麼完成業務工作的，然後才能在計算機中用代碼模擬出來
要想對軟件和計算機之外 的行業業務實現模擬，軟件工程師還要對該業務所在行業的專業知識進行一定的積累，並要超越聽懂和能執行兩個階段，才能夠用另外一種語言，也就是計算機語言表達出來，這是一個相當高的要求
因為迭代的存在，軟件會產生不同的版本，每個版本的軟件都是一個完事的開發生命流程，版本疊加的過程也就是軟件不斷長大的過程
線上版本的運行是軟件生命週期的核心，不管有多少個開發生命週期並行，線上版本都只有一個，必須確保版本上線的順序發生
十四、什麼是軟件架構
軟件要解決的問題：
業務的問題：需要明確業務的主體，並深入到業務的生命週期變化中，找到業務獨特的個性
計算機的問題：在軟件開發生命週期中，如何用計算機語言來表達業務的生命週期，明確軟件的拆分及軟件的內部組織；在軟件運行生命週期中，硬件、擴展、保證可用性、收集數據
業務問題的本質是業務所服務對象的利益問題；軟件工程師的問題本質就是要用代碼將業務模擬出來，形成軟件，交給計算機運行
簡單地增加軟件工程師並不能有效地提高產出，因為業務的生命週期只有一個，對業務的理解並不是簡單增加人手就可以解決的。只有老老實實地分析業務的生命週期，通過拆分才能提升並行度。因此需要把軟件生命週期中的活動列出來，逐個進行分析
對於軟件開發生命週期，也就是軟件工程師的核心生命週期，虛擬化業務需要完成：
學習業務知識，認識生命週期，以及生命週期中所涉及的利益相關人的核心利益訴求
通過對業務知識的學習，確定核心生命週期和非核心生命週期，以及這些生命週期的組織方式。對業務進行建模，並把建模結果交給編程語言實現，這就是業務的動作模型，也是虛擬人的組織架構
理解參與業務的利益相關人是如何和業務打交道，併為每個角色的權力和義務進行代碼描述並落地實現的
考慮如何把業務運行的結果持久化，並通過合適的手段把持久化後的數據在合適的時間合適的地點加載出來
對於軟件運行生命週期，即如何讓軟件運行起來，需要完成：
需要多少硬件設備來滿足訪問？
軟件要如何拆分部署到哪些硬件設備上？
這些軟件如何通過硬件設備連接到一起？
軟件能否支持通過部署到新增機器上的方式擴大對業務的支撐？
當硬件失效時，軟件是否能夠不影響用戶的訪問？
軟件產生的數據，能否支持提取出來並分析
按照軟件開發核心生命週期的流程，把不同的非核心生命週期串聯起來，使得這些非核心生命週期能夠並行開展工作，這就是軟件工程。所形成的就是軟件開發團隊的組織架構
軟件架構就是通過對軟件生命週期的拆分，在符合業務架構的前提下，以達到軟件本身訪問增長目的的方式。這個增長需要軟件開發的增長，也需要軟件運行的增長，由此達到所支撐業務的增長
離開了組織架構，任何軟件架構都是紙上談兵，因為架構的核心生命週期就是架構的執行
業務相當於基因，而架構樹狀拆分則相當於細胞的分裂
十五、什麼是軟件架構師
具備架構師頭銜的人並不一定是架構師
如果一個人在工作中，只是致力於完成自己的工作，以做好自己的工作為主要目標，那麼用自己行業的知識去理解另一個行業，就很容易出現溝通的困境，造成很多理解上的困難
要想成為架構師，則必須超越對時間的恐懼，看清楚要解決問題的主體是業務人員，而不是自己，即需要解決的問題是另一個行業的問題，自己是在幫助業務人員解決問題。工作是否完成由業務人員決定，而不是軟件工程師自己。
軟件工程時對時間有恐懼和壓力，是因為他們把按時完成自己的工作當成了自己的最大利益，人對時間的壓力是與生俱來的，並且對業務的不瞭解也會導致他們沒有太大的把握
軟件行業通常是以業務的問題是否解決為判斷標準，是在解決另一個行業的問題，要求架構師把完成業務的工作當成自己的最大利益，對業務領域理解得越深入，就越知道如何去發現問題，慢慢就成為業務專家了，只有做到這一點才能在業務領域建立自信，成為一個合格的軟件架構師
軟件架構師需要去拆分生命週期，並要形成組織架構去落實架構執行，而且要平衡別人的利益，甚至去調整別人的利益，必須要具備權力去調整軟件的開發生命週期和軟件的運行生命週期
架構師的核心在於架構的執行，軟件架構師必須是一個組織的領導人，有權力調動這個組織的架構，才能夠更好地發揮架構師的作用
軟件開發團隊的組織領導人其實都是架構師，只是沒有這個頭銜而已，真正的架構師不一定具備架構師的頭銜
人類架構的核心就是組織架構，正確的組織架構才能保證架構的執行
架構師面對技術很冷靜，很平等地對待所有的技術，只要場景適合就會採納，是技術的使用者，將技術當作解決增長問題的手段和工具，而不是被技術束縛住
架構師必須深入地瞭解不同的技術，知道這些技術的強項和弱點，懂得合適的取捨，不一定是所有技術的專家，沒有永遠最好的技術，也沒有永遠最差的技術，而問題總是在不斷髮生變化 的，對於這一點，架構師要有清醒的認識
架構師拆分生命週期，技術人員實現生命週期
架構師思考技術時更多地考慮技術對生命週期拆分的支撐，以及不同技術實現拆分時落地的成本和收益，以最少的成本達到更高的增長
技術是架構師手中的工具，當沒有合適的技術時，架構師會去創造技術，或者催生出新的技術
技術包括軟件技術和業務技術
技術人員如果想成為架構師，就必須跳出技術的視角，換一個角度去看技術。要把時間花在研究生命週期規律和業務的增長上，花在選擇合適的技術上，而不只是追求新潮的或自己喜歡的技術
十六、業務、架構和技術三者的關係
軟件工程師的誤區：
架構和技術實際上是等同的，學的技術越多，架構水平越高
看不上業務，覺得業務太平凡、太低調，並且業務人員總是來挖坑
通過人為創造條件，讓指定的規律按照人類的意願發生，這就是技術
所謂業務，就是要解決人類的問題，目的是為了支撐人類自身的生命週期，使人類獲得利益
技術總是在人類對業務目標要求不斷提高的情況下產生的，其目的是為了獲取更大的利益：
技術是為了解決業務問題而產生的，沒有了業務，技術也就沒有了存在的前提
有了更好的技術後，效率較差的技術，就會慢慢地被淘汰，從而消失，一切都遵從人類的利益訴求
不同技術之間有兩種關係：
在解決同一個業務的前提下，更高效、更低成本的技術，會淘汰低效、高成本的技術。這是人類利益訴求所決定的。
通常剛開始解決核心業務問題的核心技術的效率是比較低的，只是把不可能變成了可能，慢慢就會有提高效率的需求出現，改進技術的要求就會變得很迫切
業務是核心，技術是解決業務問題的工具，而架構是讓業務長大的組織方法。架構需要用技術來實現拆分，而技術需要架構來合理組織，以提升效率
產生衝突往往都是因為業務團隊和技術團隊的組織架構不匹配導致的，只有從組織架構上溝通才能解決，所以說，業務人員和技術人員的組織架構相互匹配、對應十分重要，可以減少大部分的溝通問題
很多架構師、技術人員主要專注於計算機相關的技術，看不上業務，背後的主要原因是對業務恐懼，更願意專心於自己擅長的軟件技術，因而忽略了業務，這也是為什麼技術總是和業務相沖突的部分原因
架構師應該承擔起解決業務問題的角色，專注於業務和軟件本身的架構，通過對軟件開發生命週期和軟件運行生命週期的拆分，讓技術人員合理地分工
是否重新發明輪子？
當技術所要解決的問題和拆分出來要解決的問題完全匹配時，這是最完美的
當技術所提供的能力遠遠超過需要解決的問題時，往往掌握技術和維護技術就會成為負擔
當技術所提供的能力和我們所要解決的問題部分匹配時，要判斷是否要採用，最終還是要看成本
開源的僅僅是代碼，而代碼並非是軟件生命週期的核心，軟件生命週期的核心是代碼的運行生命週期和用戶訪問生命週期，而不是代碼建立生命週期。很少企業會把自己的軟件運營體系拿出來說事兒。
要想採用開源技術，就要理解這些開源技術往往都有其特定的使用場景，一般先從理解作者面對的問題入手，也就是從業務入手，分析作者是如何拆分業務生命週期的
十七、軟件研發
軟件最初的編寫人員本身就是業務專家，業務非常精通，然後才學習用軟件來提升業務的
編寫軟件從科學計算中拆分出來，變成了一個能用的服務，成為了一個獨立的職業，具有獨立的生命週期
軟件工程師先學習計算機和軟件知識，再學習行業知識，並且軟件工程師對行業知識的掌握往往不像研究人員對科學領域所掌握的那樣精通
在業務領域，大多是如何把現有的業務在軟件中模擬出來的問題，並沒有太多高深的數學問題。如何能夠高效地把業務用軟件表達出來，並能夠隨著業務的增長，讓軟件也快速地長大，則變成了一個更重要的問題
軟件和業務最終還是要合體的
傳統行業的軟件虛擬化是對傳統行業的顛覆，但是業務本身的規律是不變的。用戶訪問企業的生命週期從現實空間轉到了虛擬空間，長大的方式從以人和空間為主變成了以計算機和軟件為主，而計算機和軟件長大的成本要遠遠你玩人的增長，虛擬空間的增長要遠遠低於真實空間的成本
把企業的業務自動化，把員工從粗糙、重複的工作中解放出來，釋放更大的生產力，成為一件必須要做的事情。而軟件在業務自動化中扮演了至關重要的角色
軟件的開發生命週期基本上都包含：確定業務需求、編碼、測試、上線
軟件開發生命週期本身就要求前一個階段完成才能夠產生下一個階段，因而瀑布式的時間推進過程是無法避免的，也不應該避免
軟件無法一次性地把所有的業務都模擬出來，必須要分步驟的一個一個階段做出來，通過用戶的反饋，一點點的長大，這就是所謂的迭代。每一個小的迭代都是瀑布式的推進。
迭代的前提是，必須要先確定優先級，而理清楚業務的核心生命週期是最高優先級
軟件的開發生命週期要允許犯錯，因為軟件模擬的是人，人與人合作總是會因為溝通等問題犯錯，只要犯的錯誤能夠得到快速地反饋和糾正就不會造成問題。所謂“敏捷”（Agule）核心就在於快速迭代並得到反饋
為了組織好代碼，架構師需要去理解業務的核心生命週期以及業務的架構拆分，形成代碼的架構；為了組織好軟件工程師，需要把軟件拆分為組件，或者拆分軟件，儘可能的讓軟件工程師之間並行工作，減少衝突；為了組織好軟件工程師，就需要形成軟件工程師的組織架構，與軟件、組件進行對應，與業務的組織架構對應
把軟件開發的核心生命週期精簡，把非核心生命週期拆分，用軟件來實現自動化，讓軟件工程師能專注於寫代碼，提升軟件工程師的效率。軟件開發業務本身也是軟件的一個業務
兩種開發模型：
以不信任軟件開發工程師為基礎，以避免軟件開發工程師犯錯為核心的開發模型
以信任軟件開發工程師為基礎，以軟件開發工程師為核心的開發模型
軟件開發的整個過程，參與其中的所有角色，都應該以軟件工程師為核心，幫助軟件工程師理解業務，讓軟件工程師成為業務專家。只有軟件工程師成為業務專家，寫出來的軟件才是靠譜的
軟件架構師要學習業務的架構，根據業務特點確定軟件開發的核心生命週期，根據業務組織架構確定軟件的拆分和架構：
組織軟件工程師進行有效的分工，形成軟件開發團隊的組織架構
減輕軟件工程師的負擔，要把軟件開發過程中的非核心生命週期拆分出來，形成軟件開發本身的業務架構，並通過自動化來提升軟件工程師的開發效率
軟件所面對共有三大業務領域及其所對應的架構：
業務領域，由業務組織架構來推動業務的架構，即業務生命週期的拆分
軟件開發業務領域，由軟件開發的業務組織架構來推動軟件的業務架構，形成的是軟件開發模式，不同角色的分工模型
軟件運行業務領域，由軟件的開發工程師來負責編寫代碼，形成軟件架構，並支撐軟件的運行，對不同的軟件開發工程師進行分工，形成不同的軟件開發工程師組織架構，以支撐不同的軟件，與軟件的架構相匹配
軟件業務組織架構和軟件開發組織架構共同組成了軟件研發團隊，業務特性和軟件開發業務的特性同時累積到軟件中，形成了軟件的架構
軟件工程師負責建設，軟件架構師負責組織
為了支持軟件工程師的工作，軟件架構師的主要職責包括：
理解業務組織架構，業務組織架構支撐並推進業務架構，背後的原因是地業務生命週期的拆分
根據業務生命週期的特點和軟件開發生命週期的特點，形成了軟件開發本身的業務體系，以及對軟件開發生命週期的拆分，也就是軟件開發的業務架構
根據對業務生命週期的以及軟件開發生命週期的拆分，形成了和兩者都相匹配的軟件開發團隊的組織架構
對軟件進行架構拆分，匹配業務架構和軟件開發的業務架構
十八、軟件的架構拆分
軟件拆分的原動力實際上是來源於業務本身的拆分所形成的組織架構
軟件是為人服務的，是為業務服務的，先有人，有業務，才有軟件，這個次序絕不可以顛倒。沒有人，軟件就推動了模擬的目標，軟件也就沒有價值了
每個業務部門形成一個軟件開發團隊，這個軟件開發團隊為這個部門生成相應的軟件，提升該部門的價值和生產力，如果業務部門內部劃分為多個子團隊，則軟件開發團隊也應該一樣劃分相應的內部子團隊
軟件開發團隊的利益來自於對業務部門需求的實現，也就是來源於業務部門對軟件開發團隊的訪問，業務團隊對軟件開發團隊的訪問通道也不能夠重用，避免不同業務部門的訪問互相沖突
從軟件團隊到人，從人到組件，形成的還是一顆樹。軟件和組件，組件和組件之間，形成的也是一顆樹
軟件的利益通過用戶的訪問來實現，和業務人員的利益保持一致，因為軟件模擬的就是業務人員，避免不同的用戶訪問通道相互影響，因此，軟件在訪問通道問題上也不能重用
重用訪問通道的結果，既損傷用戶的利益，也損傷軟件的利益，還會損傷軟件開發團隊和企業的利益
軟件架構把軟件看成虛擬的人，實際上就是虛擬人的組織架構。架構拆分的原則首先來源於業務自身的組織架構，使得軟件架構保持和業務組織架構的匹配關係；其次來源於軟件開發團隊的組織架構；最後來源於用戶的流量對軟件本身的衝擊
十九、如何寫好代碼
代碼主要由兩部分組成：
表達業務生命週期的代碼，也叫做業務邏輯（Domain Logic）或業務模型（Domain Model），要和現實生活中業務人員的職責拆分一致，並保持內聚
表達用戶訪問生命週期的代碼，就是業務生命週期對外的訪問通道，軟件的核心價值通過這部分代碼展現出來
內聚，是指某個生命週期的變化是累積在一個生命週期主體上的，而不是分散在不同的主體上，在代碼中表示一個生命週期主體，就是指一個對象。要確保一個事物的生命週期是完整的，而不是分裂的。所謂完整，就是指一個生命週期的主體，從生到死之間的整個過程中，所發生的行為和狀態是累積在一個主體上的
馮·諾伊曼體系架構，把存儲和執行分開，同時把操作也數據化，實際上都是為了模擬人。業務的操作編程，就是屬於行為的記憶
要模擬一個完整的人，就需要業務（Business）部分來實現業務的邏輯，完成對業務生命週期的模擬。業務的狀態要靠存儲（Repository）來存儲持久化，相當於現實生活中的文件櫃
服務（Service）的作用：
由於計算機和軟件沒有自己的意志，因此其內部生命週期的變化就要由外部的人來推動，這時需要提供一個訪問通道給外部的用戶。通道就是隻負責調用業務邏輯，但不包含業務邏輯。也就是服務代碼中是不包含業務邏輯的。
企業為了接待用戶的訪問，一定會設一個前臺。這個前臺就是一個服務
不同的用戶訪問，也要提供不同的服務，以避免不同的用戶之間互相影響，因為服務的重用就是自找麻煩
用戶要完成訪問業務邏輯生命週期，需要做（三個子生命週期，Service->Glue Code->Business）：
-
服務首先要把業務的狀態從存儲中加載
服務調用並組合業務邏輯完成業務的訪問（核心）
服務把業務邏輯執行後的狀態保存到存儲中
黏合代碼：業務邏輯屬於行為是沒有記憶的，而存儲屬於記憶是沒有邏輯的，要把行為和記憶黏合在一起，才能夠模擬一個人
採用存儲掛在黏合代碼上的方式，就可以讓黏合代碼成為一個完整的虛擬人，虛擬人具備記憶和行為，可以均衡地處理上述兩個問題，代碼也就劃分出了以下幾個特性：
服務專注於用戶（User）的需求，通過組織黏合代碼，也就是虛擬人所提供的生命週期活動完成需求
黏合代碼專注於管理業務中對象的生命週期，並且通過存儲保存或加載業務中對象的狀態，實現對業務虛擬人的模擬
業務專注於實現業務的生命週期活動
存儲專注於數據的保存和加載，並讓數據和存儲設備的存儲粒度一一對應
訪問邏輯的特點是組合代碼，即常見的順序調用。這種代碼裡既不會有計算也不會有if else等判斷，只有簡單的組合代碼，用於組合下一層的節點所提供的功能，方便上一層節點的調用
業務邏輯是以業務核心生命週期為主線，切分出的一個樹狀架構 ，樹上的每個節點都有其獨有的生命週期，每個節點都有一個獨立的概念來表達這個生命週期的特質
業務邏輯不是內聚的就會散落到很多其他地方去，會造成的問題：
如果服務代碼中混入了業務邏輯，則服務做了兩件或者兩件以上的事情：
典型的情況就是兩個不同的訪問生命週期合併在一個服務中來實現
如果是有計算的邏輯的話，比如受益計算、訂單金額計算等，那麼這部分應該是業務代碼需要完成的，不能交給服務代碼來實現
黏合代碼裡面如果包含業務邏輯的話，也會做兩件或者兩件以上的事情 ，會和服務代碼一樣，遇到同樣的問題
存儲代碼裡面如果混入了業務邏輯，則會導致業務邏輯進入到存儲設備中
存儲一旦變成了邏輯計算的主體，綁定數據的邏輯計算就成了一個巨大的限制 ，會導致存儲設備無法通過增加機器 的方式橫向擴展長大，只能換性能更好的機器縱向擴展（Scale up），而縱向擴展不僅程度有很而且成本也很高
業務邏輯內聚的好處：
由於服務、黏合代碼和存儲裡面的代碼都是嚴格的訪問代碼，而訪問代碼的特徵就是簡單的順序調用，因此這些代碼只要做連通性測試即可，不需要單元測試
由於業務不訪問任何計算機設備相關的上下文，不訪問任何具體的設備，如數據庫、緩存、中間件等，因為其狀態是靠黏合代碼來填充的，因此這部分代碼是非常容易寫單元測試的，而且單元測試必須保證100%覆蓋
存儲如果沒有邏輯，則很容易按照存儲設備本身的最小訪問粒度來完成工作，不需要Join
服務代碼、黏合代碼和存儲代碼只有變簡單了，才可以讓開發人員投入更多時間來研究業務
代碼架構需要注意的地方：
不能把業務模型（Business Model）當作數據對象來處理：黏合代碼需要把業務模型轉換為存儲設備的實體（Entity），實體和存儲設備裡面的存儲粒度一一對應；同樣業務模型不能拿來用作服務和用戶之間的數據交互媒介，只能轉換為DTO（Data Transfer Object）來使用
服務代碼裡不要考慮代碼重用：針對不同的角色要提供不同的在服務來服務，確保他們之間的訪問生命週期是隔離的，避免互相影響；儘量給不同角色不同的服務，既避免通道重用又降低溝通成本；服務多不是問題，服務的生命週期管理才是問題，服務治理（Service Governance）中心就是來解決這個問題的
業務模型是必須要重用的，因為這是所有用戶訪問的目標：所有服務代碼需要的，就是組合業務模型所代表的業務生命週期，用來完成用戶的訪問
服務代碼、黏合代碼和存儲代碼不能有邏輯，要克服對業務，對時間的恐懼，真正的去研究業務核心生命週期，研究相關利益人的利益，把這個變成日常的習慣。寫代碼的時候讓該出現邏輯的地方出現邏輯，讓不該出現邏輯的地方不要出現
軟件的拆分必須要和業務的拆分對應起來，此時就可看出業務生命週期分析的好處
二十、單元測試
“單元”（Unit）指的是代碼調用的最小單位，實際上指的就是一個功能塊（Function）或者方法（Method）
單元測試是一種白盒測試，就是必須要對單元的代碼細節很清楚才能做的測試，所以，單元測試的編寫和執行都是由軟件工程師來做的。
集成測試是黑盒測試，主要是由測試人員根據軟件的功能手冊來進行測試，需要有專門的測試環境配合。集成測試又分功能測試、迴歸測試等
服務代碼、管理者代碼和存儲代碼都是不需要寫單元測試的，單元測試是用來測軟件工程師自己寫的邏輯，如果代碼裡面沒有邏輯就不需要寫單元測試。單元測試代碼自身也是簡單的順序執行，並沒有邏輯，所以不需要測試。
只要出現了模擬，單元測試就開始失效了！
需要單元測試的代碼實際上是開發人員自己寫的邏輯，測試邏輯所依賴的環境是否正常不是單元測試的目的。看方法能否用一個main函數直接運行，如果可以的話就是可單元測試的代碼，該方法單元的參數，開發人員可以自由模擬，並不需要依賴外部環境
如果代碼有邏輯但不可以單元測試的話，就需要改造代碼，就是要確保邏輯代碼和外部環境相關代碼隔離，把代碼的執行順序，也就是單元的執行生命週期做架構的拆分，讓邏輯代碼單元只依賴於參數，而不是依賴於環境（不用nginx、apache等，直接php就能運行），開發人員可以自由地模擬輸入參數做單元測試。環境代碼不再包含邏輯，恢復了簡單的順序執行。
只要確保輸入參數不包含外部環境的上下文，同時內部代碼對外部的調用也不包含對環境上下文的訪問，這個方法就是可以單元測試的
寫單元測試要先搞清楚兩個問題：
要明確的是什麼樣的代碼需要單元測試，要測的是什麼——只有自己寫的邏輯才需要測，外部環境和別人的代碼不需要測
邏輯能否用單元測試來測，自己寫的邏輯單元是否可測——如果不可測，說明邏輯和訪問代碼混合了，必須讓自己寫的邏輯單元只依賴於輸入參數，就變成可測了，能夠通過main函數提供輸入參數就可以運行起來的邏輯單元都是可測的
測試基本都分為三個步驟：
構建輸入參數，並預測該輸入所產生的輸出
調用要測試的目標方法，獲取輸出
檢測目標方法的輸出是否和預期的輸入一致（Assert）
二十一、軟件架構和麵向對象
面向過程（Procedural Oriented），也叫過程式編程（Procedural Programming），會把過程式的代碼封裝成代碼塊，也叫功能（Function）或過程（Procedure），通過功能調用（Procedure Call）或者過程調用（Function Call）來組織調用的流程
越靠近硬件，越會使用面向過程的語言來編寫，比如操作系統底層、硬件驅動等，因為硬件是天然的順序執行，必須採用流程式的思維
事物生命週期推進的過程中，生命週期活動的主體是不變的，其生命週期活動的承受者就是該事物本身，這就是權責對等，也就是所謂的“自作自受”，有權力“作”，就要有相同的義務承受“作”的結果。所有的生命週期活動都作用並積累在該事物的本身，這就是面向對象，這一特性也被稱為面向對象的“內聚”
面向對象讓人們在代碼世界中，用對象來描述人類在現實生活中的分工（即生命週期的拆分），並且能夠用對象來描述自然界的分工
面向過程反映的是生命週期按時間推進的特質，而面向對象反映的則是事物生命週期活動內聚的特質
過程本身一定是某個主體生命週期中的一個過程，也就是某個對象的一個過程。面向對象的方式表述了事物的內聚，但是面向對象不能離開面向過程的基礎，也就是順序執行。對象的生命週期推進一定是通過一個個過程實現的。所以面向對象的編程語言，代碼塊還是順序執行的
大部分時候，業務的變化都是流程的變化，並且都是和用戶打交道的部分，也就是用戶訪問生命週期，所以這一部分的變動最頻繁
業務對象是很穩定的，因為分工的變化並不是經常發生，其內存邏輯也是相對很穩定的，值得依賴
繼承和多態，更多的是指事物的共性。只有封裝和麵向對象的內聚有關係。要想真正做到面向對象，就必須要去親身體驗事物的個性，也就是事物本身獨特的生命週期，才能夠真正地明白對象本身
事物有其共性，也有其自身的個性，或者說特性，最關鍵的就是其自身的特性
組合實際就是面向過程，組合其他拆分出去的對象來完成自己的生命週期。實際上已經包含了面向過程和麵向對象的兩個特質，因為組合要使用拆分的對象來完成過程的實現
對象的大小不是對象的分割因素，對象的設置要和現實的生命週期拆分，也就是分工相匹配
架構師要解決對象劃分的問題，一定要先對現實生活中的業務有親身的體驗才行。不親身體驗業務生命週期，就無法理解分工，也就是業務的架構拆分，也就無法識別生命週期的主體
對象的創建不是對象本身，而是對象的管理者
二十二、軟件架構與設計模式
模式就是在自然界或者人類設計中產生的一種可識別的規律，其重要的特徵是重複性和週期性，能夠產生模式的一般稱為模板（Template）。要想得到模式，往往要結合抽象的思維，通過分析不同事物的共性，去掉差異，提取共同點，從而得到規律
設計模式是把模式的範圍縮小限定在設計的範圍，可以理解為一種有計劃、有目的的活動，針對問題，通過對人或物進行合適的擺放，做出一個解決方案，並且還要考慮實現的成本
設計的共同點：
設計是用來解決人的問題的
設計往往要藉助已有的東西為基礎，對它們重新進行合適的定位和組合，來達到或滿足人的目標
面向對象軟件開發中的三類設計模式：
創建型（Creational）：如何生成對象，就是把產生對象的生命週期單獨拆分出來
結構型（Structural）：專注於對象的不同組合方式
行為型（Behavioral）：針對對象之間的溝通
設計模式都是把原有對象的訪問生命週期拉長，增加了環節，在不修改原有對象的基礎之上，添加新的能力或者獲得新的自由度
站在原有對象的角度來看，設計模式基本都是組合現有對象的能力，通過對原有對象訪問生命週期進行架構拆分，形成一個新的解決方案來解決特定的問題。站在業務的角度，人們創造一個事物的過程總是先建設好事物本身，再考慮如何更好地把業務和用戶連接起來
設計模式所以要解決的問題和原有對象所要解決的問題並不相同。站在組合的角度，設計模式是集合現有對象的能力，針對要解決的問題，通過某種方式的組合來形成問題的解決方案。“可重用”（Reusable），即儘可能利用現有對象的能力，通過某種形式的組合，形成新的對象和能力提供給外部
設計模式內部的分工其實是在模擬現實生活的分工。並且設計模式內部的分工往往更加的抽象，是更簡化的方式，而現實生活往往更加複雜，只有去除了具體問題的獨特性，才能讓設計模式更普遍地重複使用
軟件設計模式本身就是一個架構拆分的結果，只是這個拆分被標準化了，可以被重複使用而已。而設計模式在被使用的時候，則不需要再進行設計，直接使用即可。因此設計模式就變成了一個成熟的技巧或者技術了。
軟件設計模式這部分的代碼其實是有自己的業務領域的，這個領域就是軟件的訪問生命週期
只有從訪問代碼中剝離了所服務業務的邏輯，才有可能討論軟件訪問生命週期自身的業務模型。後續軟件訪問生命週期部分，會展開對這個業務領域的進一步討論
一個模式重複週期性的出現，是外在的表現，這些類似的現象是人們對共性抽象的結果。但是一些模式外在的表現一樣，並不代表它們背後產生的原理也不一樣，解決的問題也不一樣；同樣一個問題表現出來的模式可能並不一樣；
畢竟模式只是關注到了共性，共性只會讓解決問題變得更容易、更輕鬆，因為別人解決過了，有參考，但無法解決真正的問題。而真正要解決問題則是要發現問題的個性，發現了個性，共性才能發揮更大的作用。
要真正用好設計模式，就要和使用技術一樣，不但要理解設計模式能解決的問題，還要深刻地理解自己要解決的問題
什麼代碼都考慮重用也是一個誤區，業務對象應該被重用，但是對於服務、黏合代碼和存儲而言，它們都有自己獨特的業務問題，即它們處理訪問通道的，目的並不是給大家共享，也不是訪問的目標，而處理好通道，則需要按照不同角色的用戶來進行分析，提供不同的通道，讓它們之間的訪問互不影響。訪問通道是不能重用的。
二十三、軟件架構和軟件框架
業務呈現給客戶，並讓用戶能夠獨立訪問，形成軟件，會遇到兩大問題：
如何把業務用軟件表達出來
軟件如何被放入計算機，提供給用戶訪問
計算機軟件內部所模擬的生命週期變化 ，都是要由外部被模擬的人通過個人意志來推動。而在推動的過程中，通常會有下面這些問題：
提供給用戶什麼樣的訪問界面？
用戶訪問時，如何和用戶進行交互？
用什麼方式組織業務邏輯並對外提供訪問？
業務邏輯的狀態如何從存儲（Repository）中存取？
軟件以什麼方式在計算機中運行起來？
針對用戶的訪問問題，設計模式的典型作用就是把用戶的訪問和最終的存儲連接起來，形成訪問通道，為用戶訪問業務邏輯提供便利
模式都有一些典型特點：對用戶訪問輸入端會提供訪問的方式，並且這些訪問點可以橫向擴張；對通道下一節點訪問的輸出端也會橫向擴張，而其本身則是實現這個設計模式背後的業務。經常修改的部分，往往是輸入輸出部分的擴張，比如添加功能或者新的訪問點
MVC框架，對控制器（Controller）進行了封裝，作為其自身的核心業務，對用戶不可見，即變成透明的。模型更多的是指對視圖的數據支持，一般用DTO來表達。而業務模型關注的是業務生命週期及其行為，業務模型的內部數據只是這些行為的結果，兩者不同，但可以通過數據轉換結合來連接溝通使用，需要類似於適配器（Adapter）的模式來解決這個問題
所有通道型的框架，背後都有控制器的特質，以方便前後端接入點的擴展；也會有數據轉換的要求，以方便前後端數據的傳遞
行業類框架，是為了給整個行業提供解決方案，既要考慮整個行業的業務模式，還需要適應行業內不同企業的區別，因而往往會形成一個行業的框架
框架基本上都是根據業務模型，或設計模式等，把模型中穩定的部分進行封裝，形成一個大的邊界，但是具體內容仍留有餘地。往往是為了方便本地定製的，在本地進行改造，和自己的軟件結合在一起。
框架和服務的一個區別是：軟件引用是本地引用的方式，而服務是用來遠程調用的
要想應用個框架，首先需要理解好這個框架所能解決的問題，然後才能理解這個框架本身的業務模型和架構的拆分方式，最終才能把其他人的工作變成自己軟件的一部分
二十四、軟件運維
軟件的運行生命週期所要達到的主要目的，則是為了能夠提供給用戶持續不斷的訪問，因此軟件運行生命週期的核心是軟件訪問生命週期。軟件的訪問生命週期，從軟件接收到用戶的訪問請求開始，執行用戶的請求到返回給用戶請求的結果為止。
軟件運維其實就是指軟件的運行和維護。運維工程師本質上也是一個軟件工程師，只不過專注的領域就是計算機軟件本身的運營和維護，一旦運維軟件變得很成熟，軟件工程師就可以替代軟件運維工程師的工作，這個角色也會逐漸地迴歸到業務的軟件工程師，發生樹的節點的合併。這就是所謂的自動化。
運維的業務目標是保證用戶的訪問生命週期不受影響。也就是保證軟件穩定地被用戶訪問是運維的主要業務目標。保持軟件的運行穩定，就要求運維能夠感知軟件的運行狀態，能夠探測軟件的狀態是否超出邊界，並對之進行處理，使軟件儘快恢復正常
“虛擬人”需要依賴電力、網絡和硬件等，這些設施本身也會遇到問題，運維繫統就相當於“虛擬人”身上的免疫系統，軟件工程師就相當於“虛擬人”的醫生
運維的生命週期是從軟件部署開始的。任何對軟件的改變，都是風險，都是需要運維關注的。每次變化的風險控制是最重要的任務。
隔離，避免軟件出現在不安全的地方，可以控制所有對軟件的改變，對軟件所依賴的硬件、網絡和電力也是同樣的，只有設立隔離區才能保證軟件的安全。要區分出辦公環境和生產環境（Production）。
生產環境一旦建立，那麼生產環境就有了自己的生命週期，其內部就會開始持續不斷地發生生命週期變化，這些生命週期變化就是變更。無論是網絡上還是物理上，對生產環境上的訪問都是變更。分為：被動發生的變更、企業內部主動發起的變更
主動變更所導致的軟件系統問題大約佔所有線上問題的2/3以上。其中軟件本身的變更所千萬的問題大約佔所有線上問題的一半以上，佔主動變更中的絕大部分
線上問題無法完全避免，唯一的辦法只能是減少問題產生後帶來的損失。減少損失的辦法，要麼提前預防問題，要麼縮短問題所影響的時間，兩者都要求運維要具備快速發現並定位問題的能力。要具備這個能力就必須要時刻的感知系統的運行狀態，這就是監控（Monitoring）。
監控的目的就是把系統內不同生命週期的當前運行狀態，通過探測器傳輸出來，展示到可視或可感知的設備上，來供人查看。非常重要的指標就是實時度。
理解了軟件和業務本身的含義，才能得到軟件的數據和指標。理解了這些數據和指標，監控人員就可以對超出正常範圍的數據進行報警，馬上採取行動，儘可能在問題造成實際損害前就把問題解決掉。這就是運維的預警。
預警分為兩部分：
軟件本身業務的預警，包括軟件、硬件、電力、網絡等設備
軟件所實現業務的預警，註冊量、訂單量等等
一旦理解了業務生命週期就會發現，業務的數據會成周期性的變化，而週期性的變化就意味著可以用歷史生命週期的數據作為報警的基線
監控是生成預警的數據基礎。對業務生命週期的理解則是是生成預警的規則基礎。
預警軟件本身也是需要監控和預警的，也是預警的業務。
在生產環境做變更，也需要一個正向反饋環，這個正向反饋環核心環節就是監控和預警
變更在生產環境的執行一般稱為發佈，對變更進行管理的系統叫做發佈系統
主導變更的策略主要就是讓變更逐步地發生，一般稱作“灰度發佈”，其核心思想就是儘可用減少變更所影響的範圍。軟件要支持灰度發佈，還要要求軟件本身能夠支持兩個不同版本的代碼同時運行在線上，並且保證是對用戶透明的，不會影響到用戶的訪問
把代碼發佈和功能啟用進行架構拆分，先確保代碼上線沒有問題，再通過軟件開關來打開關閉某個功能，功能的打開和關閉就形成了一個新的發佈生命週期
生產故障時要優先恢復用戶的正常訪問，而不是在生產環境探查問題的根本原因。所有的發佈都必須要做好回退的方案，一般沒有回退計劃的發佈是不允許執行的
迴歸（Regression）測試環境，或稱為Staging環境，重點就是測試新舊功能是否都能夠正常地執行，一般用自動化來完成，因為大部分測試都是原有的功能。
功能測試環境，建立多個，供測試人員做不同版本的新功能測試
開發測試環境，避免開發人員和測試人員工享，避免發生衝突
軟件在幾個環境中發佈的推進管道（Pipeline）：開發測試環境-功能測試環境-迴歸測試環境-生產環境，所有的變更，包括軟件與硬件的變更 ，都沿著這個管道依次的通過，最終到達生產環境
軟件運維生命週期的核心是預警生命週期。也就是說，保證軟件運行生命週期的穩定是運維的核心工作
二十五、軟件訪問生命週期
訪問（Access）用更通俗的話來說就是使用（或操作）
訪問路徑：
最初：用戶->目標軟件->硬件
硬件統一管理：用戶->目標軟件->操作系統->硬件
網絡興起後：用戶->客戶端->網絡->目標軟件->操作系統->硬件
服務端拆分：用戶->客戶端->網絡->目標軟件->應用服務器->操作系統->硬件
雲服務時期：用戶->客戶端->網絡->目標軟件->應用服務器->容器->操作系統->硬件
雲服務時期：用戶->客戶端->網絡->目標軟件->應用服務器->操作系統->虛擬化->硬件
訪問路徑上的業務，都是計算機和軟件自身的業務，是為降低軟件的開發難度而沿著訪問生命週期做架構拆分而形成的
計算機和軟件自身的業務都可以歸結為訪問通道型的業務
兩種增長模式：
以複製自己的方式增長的，叫做Scale-Out，或者叫做橫向擴展
以增大個體能力的方式增長的，叫做Scale-Up，或者叫做縱向擴展
擴張沒有最好的方式，選擇橫向擴張還是縱向擴張都要根據當時社會的技術能力水平來判斷。判斷標準是對比兩種擴張方式的成本和收益，同時也要看業務擁有者本身的擴張意願
集群就是裝有相同軟件，具備相同功能的一組計算機，組織在一起共同服務於客戶的訪問。集群的路由主要考慮的因素是集群內機器的負載均衡問題，路由必須定時檢查集群內機器的健康和剩餘訪問容量
多數據中心（Data Center）可以看成是集群的集群，裝有同一個軟件的集群會同時部署在多個不同的數據中心，集群在不同的數據中心各複製了一份
數據中心前置路由策略是要把數據中心所覆蓋地區的用戶訪問歸屬到相應的數據中心，要考慮的實際上是物理空間維度上用戶的覆蓋面，避免數據中心過小而用戶過多，導致數據中心之間的負載不均衡
所謂的系統設計，目的就是為了處理好用戶的訪問生命週期，必須深刻理解用戶的訪問生命週期，也要理解訪問生命週期是如何推動並形成硬件的拆分和部署以及網絡的拆分和部署的
二十六、軟件架構和大數據
大數據並非是某一種具體的數據，也並非指數據是否大，而是相對於以前的數據處理方式而言的，是對關係型數據庫處理方式的顛覆。其實說的是新的針對大量數據的處理技術，並非“大數據”這個概念表面文字那樣是說“數據”本身
要做好大數據，真正的焦點並不在“大”，而在“數據”本身。真正的理解數據，才能夠處理好數據，讓數據產生價值
有了大數據這個工具，分析業務數據就可以得到不同生命週期的變化過程，得到不同業務決策對用戶行為的影響，可以幫助判斷不同生命週期的運轉是否良好以及整體業務運營是否和預想的一致等，這其實就是業務的監控和預警，或者叫做業務的運營
從另外一個角度看，只要對實時度和數據集大小的要求不高，關係型數據庫還是可以很好地完成任務的，理解了業務，一樣可以把業務的監控和預警做好，並不一定要採用大數據技術。真正的重點在於理解業務，而不是技術本身。有些場景下，關係型數據庫還是有自己的優勢的。
用戶對軟件的訪問生命週期體現了業務的訪問行為，也同時體現了軟件本身的訪問行為，因此訪問日誌（Access Log）可以被用於業務數據分析和軟件本身的業務分析。所有的服務器都帶有訪問日誌，不需要額外的開發成本。
當業務需要從大量的軟件訪問日誌中抽取用戶的業務行為時，也是典型的大數據應用場景
得到的數據只是一個表象，簡單的收集數據並不能解決問題，哪怕採用大數技術也是一樣。不理解這些架構的拆分，不理解這些拆分出來的生命週期的積累，是無法理解數據的。因此，架構對於大數據處理至關重要。
軟件的大數據分為兩部分：
一部分是業務的監控和預警，由業務方來執行
一部分是軟件本身的監控和預警，由運維團隊來執行
由於業務運營的數據往往來源於運維團隊，所以業務的運營少不了運維的支持和參與，也就是說業務的運營會訪問運維團隊。針對不同的業務業務團隊，運維團隊內部還要對此進行分工，形成不同的訪問通道，避免不同的業務方互相干擾，從而對自己產生不必要的溝通成本
二十七、軟件架構和建築架構
軟件架構和建築架構都是為人服務的，兩者在這一點上是一致的，都是為了解決人類自身生命週期的問題，對世界做的一個拆分。並且拆分的結果，都是對人類形成了分工。拆分的目的，也都是為了延長人類的生命週期，提升人類生命週期活動的推進質量。
很多人認為架構就是一個框架或架子的原因就在於，要知道框架和架子的目的僅僅是為了實現架構對空間的切分，屬於實施的技術，並非架構本身
軟件的目標關注的是把人們所做的事情模擬出來，把人從重複的勞動中解脫出來。世界是週期變化 的，意味著軟件一旦把這些週期模擬出來、管理起來，人們只需要按照自己的需要，推動這些生命週期為自己服務即可，不需要親自去執行這個週期，軟件所關心的是人類生命週期的切分，把人類自身執行生命週期活動以外的非核心生命週期用軟件來模擬實現，讓人可以有更多的時間來算下推進自己的生命週期，提升生命質量
建築的設計建造往往是由建築公司來做的，運營可以完全交給物業公司；而軟件目前做不到，必須要自己運營；建築可以出租給其他的用戶來使用，軟件的出租比較難，只有娛樂軟件或標準化的軟件相對容易些；
有了軟件之後，人的一輩子能夠作出更多的創造，達成更多的目標，也相當於延長了人的生命
建築擴展主要是橫向擴展，由一個一個的個體建築，形成了社區、城市和國家，縱向擴展可以理解為重新裝修，改善居住空間
像建築一樣的瀑布式開發並不理想：
一是由於人們對軟件的認識還遠遠達不到對建築的認識程度
二是建築的訪問增長是可以預測的，而軟件則不可預測
軟件的優勢是建造非常簡單的代碼，不僅原有的設施可以直接使用，而且每次發佈都可以重用以前寫好的代碼，只需要做增量的修改即可；建築的模塊化程度也遠低於軟件；
二十八、交易
交易就是人們各自拿自己多餘的物品，從其他人手上換取自己必須的物品，從而雙方都獲得利益的過程
所謂市場，就是指集中發生交易的地方，每個人都可以在市場上賣自己的物品，也可以在市場上尋找自己想買的物品
用單位時間增加的產出去換取另一個人對應時間增加的產出，大家都用比較少的時間得到了更多的回報。因此，慢慢也出現了很多人直接用自己的時間與人交易，得到自己的生活必須品，這就形成了僱傭關係，從而變成了職業
企業通過對生產的生命週期分工，僱傭更多的人，組織他們並行工作，可以得到更大的產能，甚至1+1>2的效果，這就是企業的組織架構
促使用戶訪問軟件的動力，就在於軟件的虛擬化極大地減少了人們獲得物品的難度，所有獲取的信息量更大，因此，要評價一個軟件的價值，它的訪問量是一個至關重要的衡量標準，因為每一次用戶的訪問，就相當於該軟件所產生的一個交易
交易的背後實際上是人們互相之間時間的交換，而不是貨幣。貨幣只是對時間的定價，方便交易的一個工具。對於不同的商業模式，交易都有自己的形態，需要人們識別出來
企業的生命長度可以遠遠超過一個人的生命長度，所以很多人會把企業當作自己生命的延長來付出。企業要具有比人長的壽命，就要超出個人的訴求，不再為某個個人服務，而是為了一個群體服務，形成了企業的核心訴求和目標，也就是人們常說的企業願景（Vision）
企業在達成願景的過程中，其生命週期由一個一個和用戶的交易積累而成。交易又由一次一次的訪問生命週期積累而成，這就是企業生命週期的動作過程，也是企業生命週期的架構拆分
組織架構的目的就是通過更多人的並行工作，來支撐更多用戶的訪問生命週期。無論哪種企業，交易的最終實現，都是通過用戶的訪問來達成的。訪問是如何達成的，訪問生命週期是如何切分的，則是不同企業的區別之處，也是不同企業願景的入手點
二十九、產品
交易過程中，人們交換的物品被稱為產品（Product），有時也被稱為商品（Good）。產品配上主語就是：誰生產的一個東西
人類要訪問產品，首先要有一個訪問目標，即產品本身，其次還需要一個訪問的途徑，兩者都具備才能夠達成對產品的訪問
製造類的產品要能夠讓人類訪問，必須要到達人類的感覺範圍內。因此必須要建立空間的渠道，經歷時間傳輸到用戶的感覺範圍內，用戶通過自己的感覺器官才能夠接觸訪問到產品
為人類提供對製造類產品訪問的空間通道，所形成的便是服務類的產品，也就是通道類的產品
產品更多的是表達生產屬性，而商品則更多的是表達交易屬性。產品本身不一定能夠售賣，但是售賣的東西一定是某個產品，也就是說一定是某個主體所生產的產品
從用戶角度看，在達成交易之前 ，用戶尋找的是解決自己問題的產品。而在尋找到自己想要的產品之後交易時，用戶考慮的則是數量和價格，交易時購買的是商品。在用戶使用的時候仍然是產品，也就是產品屬性
對於一個企業來說，如果這個企業的領導人對自己企業的願景不夠清晰的話，往往會帶來一個嚴重的問題，就是這個企業的產品往往是模糊的。產品不清晰導致的結果就是：目標人群不清楚，產品體系混亂，進而導致組織架構混亂 ，交易很難增長，企業也會陷入困境
要讓用戶知道這個產品，就必須要把產品所解決的問題等信息傳播出去，使得目標用戶能夠訪問到這些令牌，通過這些令牌吸引用戶來訪問產品的入口，讓用戶產生交易的意願，這就叫做市場營銷（Marketing）
產品本身就是最好的營銷。產品系統實際上是市場營銷的起點，也是交易的起點，也是企業用來實現自己願景的工具，是願景的具體化
產品列表（產品目錄）要展示的信息，就是把企業的願景傳遞給用戶，取得用戶的認同併購買。把產品列表向目標人群分發，就是產品的營銷
商品規則：
從商品本身為出發點的，一般是來提升商品本身的銷量。比如優惠價格、評價優惠等
從客戶本身為出發點的，一般是用來提升用戶的數量，或者提升用戶的活躍度。比如新用戶優惠等
從支付推廣為出發點的，一般是用來提升某個支付方式的使用率。比如啊啊服務號信用卡優惠等
三十、用戶
用戶，用的是某個主體生產的產品。當某人正在使用某個主體生產的產品時，一般會說此人就是這個產品的用戶。用戶表達的是產品運行生命週期中所服務的人或人群
客戶（Customer），更多的是關注在交易層面，是產品銷售的對象，也是交易的對象，目標是為了讓產品的客戶成為產品的用戶
用戶這個概念是針對產品生產者，也就是企業而言的，目的是為了把用戶處的信息，通過某種方式蒐集到企業這裡，是企業對其產品使用方建檔並跟蹤的一個原始數據組織
任何產品都需要用戶，因為產品的生產都是為人服務的。用戶對於企業是至關重要的，任何企業都是由人推動往前發展的。企業只是人類需求的一個實現形式，因此企業時刻都要以人為本
要讓人們成為企業產品的用戶，企業必須要把產品賣給客戶
用戶的產品使用行為記錄基本上靠用戶主動反饋的產品使用信息，企業有責任幫助用戶解決產品訪問和使用上的任何問題，這就是產品的運營。用戶的信息一直保留在企業處，這是企業非常寶貴的數據，也是下一輪銷售生命週期的起點
企業應該投入資源從通道處獲取自己產品的訪問情況，用來提升自己的產品
三十一、訂單
訂單，就是指和客戶的一次交易的生命週期過程，實際上是所售賣產品的訂單，表述的是產品的售賣過程，售賣的東西是產品中的某個商品。訂單所代表的就是一次交易的整個生命週期過程，從交易生成開始產生訂單，到交易結束為止完成訂單
其實複雜的事情一開始都是簡單的，簡單的東西逐漸地發生拆分就變得越來越複雜了
三十二、交易系統
一個交易是需要兩方來形成的，一是賣方，還有一個願意購買的買方。要兩方同時達成一致才能夠形成一個交易。
企業願景的達成依靠企業所生產產品的售賣，通過交易建立起客戶獨佔訪問產品的通道，使企業和客戶都獲得更大的利益，形成雙贏的結果
企業的交易生命週期是核心生命週期，企業的生產是為交易服務的
產品訪問通道是交易系統能夠運作的前提。為了把產品展示給客戶，一般就會要求產品的負責人把所有產品整理好，用來供用戶查詢，這就是產品系統
為了跟蹤客戶使用產品的問題，還需要把客戶的信息和購買行為記錄下來，這就形成了客戶系統
有了用戶的購買行為和聯繫方式，客戶的通道就建立了。利用這個通道就可以在適當的時機推薦合適的產品，或者在客戶兩次購買的時候，快速的幫助客戶選擇到更合適的產品，這就是營銷推薦系統
一個企業的交易生命週期和訂單生命週期是核心生命週期，而產品、用戶等生命週期都可以不用自己親自來做，但訂單是非要自己來做不可的
對於架構師和軟件工程師來說，如何快速識別模型需要對業務的生命週期進行深入瞭解，要對業務的特性有足夠的認識和體會。對業務系統的建模來源於業務本身生命週期的拆分，即組織架構的拆分。建模實際上就是把人虛擬化，把各業務系統負責人的工作用模型表達出來。模型中的每一個對象，代表的就是現實生活中一個個活生生的人。這個對象的方法，代表的就是這個人所負責的業務生命週期行為
“阻抗不匹配（Impedance dismatch）”，兩個東西完全不匹配，放在一起反而會互相干擾造成更大的問題
業務模型完全就是現實社會中已存在的分工，建模的人只需要識別出來就可以，不需要再絞盡腦汁用不同技術抽象出來另外建一個模型來表達業務
軟件模擬業務的展現方式總是儘量模擬現實生活，讓用戶感到是“真實的人”人在服務於自己。軟件的一切都是在模擬人的行為
訪問通道的另一個非常重要的要求就是，不同類型的用戶訪問要提供單獨的訪問通道
很多架構師喜歡做訪問通道的重用，往往會導致不相干的另一類用戶訪問受影響。不重用訪問通道的目的是為了重用業務對象。一旦重用訪問通道，業務對象中的業務邏輯一定會分散到訪問通道中，業務邏輯反而得不到重用了
在計算機軟件中，服務的本身是客戶端訪問服務端的訪問通道，是不包含所服務的業務的。一旦軟件發生了架構拆分，原來的本地調用就變成了服務調用
服務有自己獨立的生命週期，會形成自己獨立的業務，不再依賴於原核心生命週期，煥發出新的活力
架構拆分最終都會形成最小粒度的生命週期，粒度有多小取決於業務本身的規律，也取決於當前技術的發展水平
用戶系統的核心是為了能夠標識用戶，讓用戶能夠以獨立的身份訪問系統，從而軟件可以識別並跟蹤用戶
做架構的拆分不會影響外部，而影響外訪問行為的拆分都是業務的破壞，應該叫做結構變化或業務變化
三十三、事務
在英文中，Transaction的含義是交易的意思，指的是物物交換。
在軟件中實現交易的時候，一般是通過訂單來記錄各方的當前狀態。交易中過往行為的記錄，則是通過操作日誌來實現的。操作日誌和訂單記錄結合起來模擬人類大腦的記憶。所謂回滾，也是通過已執行操作的日誌記錄，按發生順序反向執行恢復反向操作來進行的。因此，交易日誌在軟件中是至關重要的。
軟件把內部運行中的生命週期狀態交換給數據庫來保存，而數據庫本身獲得了生存，有了自己的生命週期，形成了新的存儲技術。而為了確保把軟件的狀態可靠的存儲，可靠的獲取，就需要一定的機制來保障這個交易，這就是數據庫的Transaction技術，也就是所謂的事務，應該就是要達到可靠數據交換的緣故
數據庫應該完全和軟件所模擬的業務脫離關係，應該恢復到其本身的作用上來，即持久化軟件的狀態，並且僅僅持久化軟件的狀態
數據庫事務只應該存在於和數據庫打交道的存儲代碼中
假設被調用的兩個服務不是在同一個事務中：
第一個服務不成功，說明整個調用操作是失敗的，沒有影響
兩個服務都調用成功，說明整個操作是成功的
一個成功一個失敗
調用方收到錯誤提示後自行
重試每個服務的調用
將第一個服務做反向操作，恢復現場，需要操作日誌的幫助，如果不能恢復，則需要人工介入解決，恢復數據
導圖：
https://github.com/zhangyue0503/blogfile/tree/master/%E8%81%8A%E8%81%8A%E6%9E%B6%E6%9E%84
閱讀更多 硬核項目經理 的文章
