項目架構

大多數的程序員，都是作業務開發的，我也是。天天的工做都圍繞着產品的需求。咱們總在不停地寫需求，在不停地堆砌代碼，還在不停地解決Bug。後來，咱們愈來愈陷入細節，愈來愈不能把握全局。

對於一個新的項目，你準備怎麼設計它？或者，對於一個新的需求，你準備怎麼設計它？

代碼的組織結構，自己也是一種架構，好比MVC。在實際工做中，咱們都喜歡對代碼進行分層，好比，將代碼分紅了以下幾個部分，controller面向具體業務提供服務；service也提供功能的實現，但不針對業務；mapper主要針對數據層：

---- controller
---- service
---- mapper

而後，對於數據層，你會選擇什麼做爲存儲，MySQL、Mongo或者Redis。對於高QPS的場景，準備如何使用緩存？是否須要使用本地緩存？是否使用異步進行處理？這些都應該屬於架構的範疇。

或者說，先總體規劃要實現哪些需求，給需求劃定邊界。而後，分析要扛住多大的併發，而後如何支持後續的擴展。

根據此，嘗試簡單描述現有的服務：項目代碼採用相似MVC的結構進行組織，根據Path來路由請求，底層目前主要使用MySQL做爲存儲，依賴MySQL的事物處理機制。對於一些其餘的狀況，咱們還採用Kafka來實現異步處理。