有好幾個群友問我為什麼最近更新變慢了。工作忙是一方面，另一方面是我更新文章的動力確實下降了。近大半年一直在更新的《對線面試官》系列，到現在已經40篇了。
說實話，當時我更新該系列有很大一部分是為了自己的面試。而現在入職了以後，短時間內也不會跳槽了，所以更新該系列的動力就自然下降了。
話說回來，我前段時間在面試的時候，照著《對線面試官》系列所準備的知識，基本都沒太大的問題。
最近我在工作做的事情還需要不少的時間沉澱，短時間內又寫不出比較好的文章跟大家一起分享。
基於以上的問題，這段時間就好像進入了死迴圈，出不來了。
01、想法
有很長的一段時間，我都在想要不要寫個「小專案」持續迭代。
這樣一來，我在空閒的時間就可以繼續寫程式碼了，並且在寫專案的過程中又會潛意識督促自己不斷地學習。
之前空閒的時間都在碼文章和學習，基本沒怎麼寫程式碼的（：
在工作倒是一直寫程式碼，只不過寫的程式碼都不是我喜歡的。
雖然自己的程式碼寫得很爛，但自己並不覺得自己的程式碼很爛。很多時候感覺自己的程式碼寫得挺好的，而同事進來做了一把需求，感覺程式碼又變爛了。有沒有人跟我有相同的想法？
自從畢業工作了以後，就越來越發現自己所掌握的知識都是片面的。絕大多數人去到公司，技術環境都是搭好的，對應的技術都是封裝好的，而我們只是在現有的基礎之上修修補補。
很多時候我們沒得選，公司用什麼就一直用什麼。除非自己開個新的專案，做新的功能，並且經過調研之後可能我們所想的技術棧能在自己的專案中用得上。
02、難點
我還記得我以前大leader曾經在一次會議上說過：現在你們能做到這麼多事情，很大原因是有公司這一整套環境。假如你離開了公司，你能搭建出來並且完美執行嗎？
我站在我當時所維護的系統角度來想了下，認為確實比較難。
當時我維護的是觸達系統（簡單理解就是給使用者發訊息的），聽著功能很簡單，但實際上裡邊用到的技術棧還是蠻多的：RPC呼叫、分散式配置中心、Redis、Flink、MySQL、SSM開發環境、MQ、規則引擎、ELK日誌、分散式定時任務排程、Hive、Elasticsearch等等
基本是把主流的Java後端技術棧用了個遍(：
有的人可能就會有疑問了；你核心的功能這麼簡單（就發個訊息），在生產環境下你是真的用上了上面所講的技術棧嗎？你不會是寫部落格就在這裡吹牛逼吧？我不信。
其實是真的用了這麼多，且每個技術棧都有存在的必要性：
- RPC呼叫：例如，營銷訊息需要依賴DMP（使用者畫像系統）資料，需要呼叫DMP的介面。微信類訊息需要accessToken，需要呼叫使用者服務相關介面等等，這些依賴都需要遠端呼叫（遠端呼叫在程式碼側比較優雅的就是RPC呼叫了）
- 分散式配置中心：靈活配置各類資訊，這種技術框架就是YYDS。例如：可以把限流的值寫在分散式配置中心，那限流的速率就可以靈活改動了。
- Redis：高效能記憶體讀寫，可以用來去重過濾或者統計資料。例如：使用Redis做去重功能（有TTL時間非常適合訊息下發業務）
- Flink：實時流處理平臺，可以用來清洗埋點的訊息（所謂埋點的訊息實際上就是訊息鏈路資料資訊，在訊息下發過程中記錄關鍵鏈路資訊）
- MySQL：儲存需要事務支撐資料或者變動較少的元資訊儲存。例如：小程式模板的元資訊就可以儲存在MySQL
- MQ：系統解耦、非同步和削峰的好助手（接收埋點資訊或提高響應介面速度）。例如：大量的日誌資料可以先扔到Kafka
- 規則引擎：結合分散式配置中心可做到常見需求無須系統釋出即可實現。例如：把簡訊接入的邏輯寫在規則引擎中，新的簡訊接入無須釋出系統
- ELK日誌框架：排查處理問題好幫手。例如：在關鍵的地方打上log，不再登陸每一臺機器上看日誌，直接通過關鍵字搜尋
- 分散式定時任務排程：叢集環境下定時更新資料以及觸發任務。例如：營銷訊息會根據時間定時傳送，在叢集環境下使用定時任務排程框架指派某一臺機器觸發
- Hive：離線資料儲存，助資料倉儲得到觸達平臺資料
- Elasticsearch：觸達後臺頁面按內容/標題匹配查詢資料
- ....
可以看到列出的技術棧，每項技術都是可以深入地去研究（有一定規模的公司裡，上面提到的每一項技術都會有專門的開發人員去迭代和維護）。
除了列出來的後端技術棧，一個比較成熟的專案，還有很多的細節，包括但不限於：監控告警、自動化整合部署（釋出）、負載均衡（Nginx）這種運維側的東西。
這些東西光靠一個人確實是很難做得比較完整的（：
03、血賺
入行以來，我一直充滿都著好奇心。想知道某些業務場景是怎麼玩的，某些技術是怎麼玩的，自己所負責的東西哪裡存在缺陷，有什麼地方可以改善的，跟別人家公司同類的系統相比是怎麼樣的，還能怎麼繼續提升。
但由於公司相關的內容是不能隨意公開的，所以很多時候就是"閉關鎖國"自己造著玩。（至於系統好不好，自我感覺是良好的。跟別人有多大的差距，我也不知道）
現在看我的公眾號有小白，也有很多大公司的大佬。
假設我有不錯的經驗分享時，小白看完之後能夠借鑑我的經驗進而提升自己，我感覺我寫的東西就很值了。
當我的程式碼實現或思想已經是落後時，如果能有大佬幫我指出，我進而學習並調整，我這又是一波血賺。
04、專案內容
我以前做的是廣告和觸達系統的，對別的專案就不太瞭解了。我還是學生的時候，網上很火的是商城專案（不過現在好像也很火）。
以前還沒工作的時候我不懂為什麼網上這麼多做商城的專案，現在工作了以後，我就更不懂了。
網際網路業務其實非常多，電商只是其中一個業務
以前有幸擔任面試官，面過一些實習生，好多簡歷上也是寫的商城。對於這類專案，我問起專案或技術細節，幾乎都表達得不怎麼樣（商城這類專案，很多功能在真實開發場景業務，感謝商城這些系統對於初學者而言，還是有些晦澀）
（：像秒殺什麼的，據我瞭解，在生產環境下也遠沒想象中那麼複雜。
這次從零開始寫專案，我想還是以【觸達系統】為主，這玩意比較好理解，並且幾乎每家公司都會有這類的系統（如果沒有，那就該換一家有的）
05、文章更新
專案不會很快地就迭代成型，我是打算以部落格的形式來一直迭代更新，這個過程能聊的東西還是很多的，有的內容可能我也不太確定，也會發出來一起討論討論，比如說：
- 在構建專案的時候，我會講講為什麼用Maven，為什麼用SpringBoot
- 在寫業務程式碼的時候，我會講講為什麼我是自己喜歡寫單表結構，而不join或者各種子查詢
- 為什麼這個場景要用分散式配置中心，為什麼要用規則引擎，能帶來什麼好處
- ..
想法有很多，自己也有很多不熟悉（我所講的未必是對的，但是經過交流和深入學習之後，我還能把我的思考過程再梳理一遍發出來），我覺得在這個過程，對於小白新人來說，都會有所收穫。
其實很多細節我也還沒考慮好，比如前端對我來說就是件比較頭疼的事（不過這兩個月我預估都不會碰）
我發現還蠻多人挺在意我前端使用什麼技術，到時候怎麼寫。
說實話，我也不知道。我前端在大學的時候搞過HTML+CSS+JavaScript+jQuery+Ajax+BootStrap，作為後臺頁面大概能用的效果。
我畢業聽得比較多的都是Vue+Angular+React了，還有Node.js的環境等等，這些我一個都沒學過（我目前也提不起興趣去學）
前端這塊還有很多細節敲定，到時候再說吧。說不定到時候或許可能大概有大佬可以支援下呢？不過很可能還是我自己來寫，畢竟我自己能做到的事情，也沒必要麻煩別人。
所以，今天先更新下austin的介紹以及Q4對austin專案的安排吧，後續等我這個Q的安排做完了，我就繼續補充第零篇。
站在我的角度，我認為：austin專案的業務很簡單，可玩性很足，能用到的技術棧也很豐富，比較適合初學者。
後面在寫的時候，我會穿插些我認為專案的亮點，我的目標是：該專案會成為Java小白簡歷上的一個專案（不再是清一色的商城專案）
06、專案介紹
austin專案核心功能：傳送訊息
專案出現意義：只要公司內有傳送訊息的需求，都應該要有類似austin的專案，對各類訊息進行統一傳送處理。這有利於對功能的收攏，以及提高業務需求開發的效率
07、專案流程圖
austin專案核心流程：austin-api接收到傳送訊息請求，直接將請求進MQ。austin-handler消費MQ訊息後由各類訊息的Handler進行傳送處理
Question 1 ：為什麼發個訊息需要MQ？
Answer 1：傳送訊息實際上是呼叫各個服務提供的API，假設某訊息的服務超時，austin-api如果是直接呼叫服務，那存在超時風險，拖垮整個介面效能。MQ在這是為了做非同步和解耦，並且在一定程度上抗住業務流量。
Question 2：austin-stream和austin-datahourse的作用？
Answer 2：austin-handler在傳送訊息的過程中會做些通用業務處理以及傳送訊息，這個過程會產生大量的日誌資料。日誌資料會被收集至MQ，由austin-stream流式處理模組進行消費並最後將資料寫入至austin-datahourse
Question 3：austin-admin和austin-cron的作用？
Answer 3：autsin-admin是austin專案的管理後臺，負責管理訊息以及檢視訊息下發的情況。業務方可根據通過austin-admin管理後臺直接定時傳送訊息，而austin-cron就是承載著定時任務的工作了。
08、專案技術架構圖
2021-11~2021-12實現功能：
實現功能所需引入的技術棧：
Gitee連結：gitee/austin
GitHub連結：github/austin
關注我的微信公眾號【Java3y】聊專案！【對線面試官+從零編寫Java專案】 持續高強度更新中！求star
原創不易！！求三連！！