有好幾個羣友問我爲什麼最近更新變慢了。工作忙是一方面，另一方面是我更新文章的動力確實下降了。近大半年一直在更新的《對線面試官》系列，到現在已經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
原創不易！！求三連！！