353 stars Java專案！Java小白必看！austin介紹【第一話】

Java3y發表於2021-12-02

Java

有好幾個群友問我為什麼最近更新變慢了。工作忙是一方面，另一方面是我更新文章的動力確實下降了。近大半年一直在更新的《對線面試官》系列，到現在已經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小白簡歷上的一個專案（不再是清一色的商城專案）