最近一直在回顧和總結以往開發過程中用到的一些技術，例如redis、dubbo、kafka、zookeeper、spring、mybatis等等，發現以往對這些技術的理解僅限於使用方式和技術實現細節上，在腦海中一直無法完整的把這些技術串聯起來，也不能很好的在實際場景中，根據不同的業務需求來做出技術選型，我想，這和我對IT系統架構演進過程以及每種架構模式應對的業務場景及帶來的問題不是很清楚有很大關係，所以藉此片文章，來總結一下對架構的理解。這篇文章準備作爲現階段學習和總結的一個主線，持續更新和修改。
我總結自己是一個愛學習但不善於思考的人，所以，雖然在很長的時間裏花了大把的時間去學習，但是收穫並沒有想象中的大，可以說事倍功半，主要原因在於缺乏思考，雖然現在年紀大了，不過能及時認識到自己的問題，也是極好的，魯迅老先生曾經說過，種一棵樹最好的時間要麼是十年前，要麼就是當下。
那對於我們程序員來說，每天面對最多的就是無窮無盡的crud、與產品經理互相傷害以及由此引發的對人生意義的思考，曾經我以爲crud沒有意義，憤然離職，但是直到此刻，我才意識到，無論是curd還是與PM的互相傷對我們程序員來說都非常有意義，關鍵就在於如何“思考”。如果在curd的時候想一下每一次代碼的執行流程，如果在撕逼的時候能想一下業務背後的邏輯，或許會有完全不同的結局。
寫了這麼多廢字，下面進入主題。
首先，聊聊架構是什麼。架構架構，就是架子的結構，架子是支撐一件東西的主體結構，例如下面這個哥們
但是架子並不是一成變的，上面的兄弟是人的架子，但是貓狗蟲魚豺狼虎豹的架子並不是這樣，每種動物的架子都有他自己的結構，所以總結一下，架構就是支撐起某樣東西的架構對應的結構，在不同的領域，架構的具體體現也不一樣，例如，在建築領域，移動樓的架構就是主題房梁，有高矮胖瘦之分，這個架構的主要作用是支撐起每個格子間或者每一個家庭，在人力資源管理領域，架構有多叉樹（原諒我不知道專業術語）結構和扁平化結構，作用是支撐起一個組織的人員管理等等。
那反觀IT系統架構，體現形式有單體架構、集羣架構、分佈式架構、Service Mesh架構，這些架構需要支撐起我們的業務，爲老闆賺錢。不同種類的架構都有其自身的優缺點，針對的場景也不相同。
1946年世界上第一臺計算機“艾尼阿克”在美國誕生，到後來ATT的Unix系統，再到1991年發佈的第一版Linux，計算機操作系統經過了半個世紀的發展逐漸走向成熟，於此同時，計算機硬件也在摩爾定理的指引下高速發展，直到最後PC的普及，促進了Web1.0到Web2.0的進化，再到現在，智能手機的普及，締造了移動互聯網，隨着5G的發展，萬物互聯可以說指日可待。在技術發展的過程中，IT系統作爲互聯網世界的最小單位，也在不斷的進化。
先來說說簡單的架構模式-單體架構，從最初的LAMP到現在的SpringMVC+MyBatis都屬於單體應用。早期，由於互聯網發展初期用戶基數較小、因爲相對比較簡單，採用單體架構，把所有東西都放在一起，也能夠很好的支持業務，同時，部署簡單，可以快速響應需求。即使是現在，對於一些小的服務還是會優先採用單體架構，。
在單體架構的基礎上，如果在服務性能上無法滿足需求，可以做對等集羣部署，前端通過nginx或openresty做反向代理，數據庫層的讀寫分離，一般這種集羣架構能夠支持很長一段時間。
在集羣架構中，經常需要面臨的一個問題是會話狀態同步，目前能想到解決辦法有四種，分別是
- 通過tomcat提供的插件解決
- 通過spring session解決
- 通過共享會話緩存解決
- 通過ip（會話）粘連解決
對於前三種都沒有見過廬山真面目，只實踐過第四種，因爲這種方式實現最簡單，通過nginx配置就可以完成。不過目前比較流行的解決方案是基於類似JWT的無狀態設計來規避這個問題，Session同步這個問題不管怎麼解決都感覺不夠優雅。
此時，如果系統在性能方面還是無法滿足業務需求，那麼就要請出解決高併發問題的三把瑞士軍刀之一 - 緩存，實踐證明，緩存可以極大提升系統性能，延長系統架構的生命週期。
目前比較流程的緩存技術就是redis了，redis是一個非常強大的東西，可以用來做緩存、內存數據庫、消息隊列、實現分佈式鎖等等，有人可能會說memocahe，我只能說沒用過。
使用緩存時，我們面臨的問題通常有兩個
- 如何保證雙寫一致性
- 如何避免緩存穿透/擊穿，以及緩存雪崩的發生
保證雙寫一致性也是一個比較讓人頭疼的問題，目前能想到的是把設置緩存過期時間作爲保底，然後選擇一個合適的緩存更新策略。跟新緩存的一般思路無非就是
- 先更新數據庫再更新緩存
- 先刪除緩存再更新數據庫
- 先更新數據庫在刪除緩存
另外還有一些對性能要求極高的系統，例如秒殺，一般會直接屏蔽掉寫數據庫這一步，首先做緩存預熱，然後服務直接操作緩存，後臺在通過消息隊列或定時器來將redis同步到數據庫中，對於緩存穿透、擊穿、雪崩這個老生常談的問題就不在這裏展開了，可以跳轉到www.baidu.com
但是，隨着流量、業務複雜度以及團隊成員的不斷增加，單體架構或集羣模式帶來的弊端越來越明顯，產生大量的重複代碼、業務耦合度過高、單次部署需要的時間越來越差等等，這時候就需要考慮對服務進行拆分了，拆分的時候，可以根據系統的特點，採用橫向拆或縱向拆，如果業務邊界比較明顯，那就可以縱向拆，把整個服務拆分成不同的相互獨立的子系統，但是如何業務之間的調用比較多，就需要考慮橫向拆，把每一個獨立的功能拆分成一個服務，獨立維護和部署，這時架構也就演進到了SOA模式。
早期的SOA架構通常基於WebService實現，還有人說基於消息總線實現，由於筆者比較年輕，所以也沒接觸過。現階段所說的SOA架構通常指的是基於Rpc實現的（這裏可以拍磚了），SOA架構涉及兩大問題，一是實現跨進程跨網絡調用，二是服務治理。目前有很多比較有效的rpc框架，例如grpc、thrift等等，但是這些都不具備服務治理功能，算了我還是直接說dubbo吧，dubbo可以說是目前非常流行的一個實現SOA架構的框架了，它提供了包括服務監控、服務降級、集羣容錯等一些列高級特性，來解決SOA架構中的問題。
另外，在某些場景下SOA架構還設計到API 網關，這裏的網關一般是我們自己實現的，主要用來做功能的聚合以及一些安全訪問控制等。