前言
這篇創作的初衷其實也是看了很多大神們的總結後，油然而生的一個想法，唉，我是不是也可以總結一下，順便幫助自己把思路再熟悉一下，當然如果對你有一丁點的幫助將是我莫大的榮幸，所以這篇就來了。本來以爲可能需要花費一週的時間來準備材料，後來由於工作的原因，就想到哪裏寫到哪裏了，話不多說，上圖。
正文
如上所說本來是想拿網上一個的簡單的系統來拋磚引玉，但是還是算了吧（以後有時間再補充吧），上來就幹，就是我的風格。有的人看了這個圖之後就納悶了，我一個搞java的，你給前端知識幹什麼，小夥子，你是不是沒有聽說過全棧呀，另外以前前後端不分離的時候，都是後端寫的前端呀，當然現在難度大了，畢竟前端現在發展那叫一個光速呀，前面框架剛學會，又出來一個新框架，還更好，你說找誰說理去，真是欲哭無淚呀，扯遠了，扯遠了，來，一、二、三，收！
前端
這兩年沒有寫過前端了，以前寫的還是用JQuery和Easy-UI，也用過一點vue，現在聽說比較流行的是vue、react，並且爲了適應不斷的前端需求變化，都是前後端分離的，所以肯定需要自己的打包工具，webpack就用上了，至於開發工具，因人而異吧，Sublime Text、WebStorm都行，倉庫管理工具Git。
好，前端說完了，那是不是要說說後端了，別急，小兄弟，數據都是存儲在後端的，那麼前端是怎麼樣去後端拿數據的，之間又是怎麼交互的，通常我們所說的都是後端提供接口給前端來調用，這個時候網絡協議開始粉墨登場，HTTP請求，再熟悉不過了，什麼get請求、post請求、put請求等，這個沒有問題，那麼請求的參數呢，什麼格式的，AJAX，Asynchronous Javascript And XML，當然參數支持XML和JSON格式，但是JSON格式後端接受要使用@ResquestBody註解，當然隨着技術的不斷更新的，後來又出現了AXIOS、FETCH交互方式，號稱更好更安全。
上面正好提到了網絡協議，正好這裏一起講了，正常的OSI模型分層是7層，應用、表示、會話、傳輸、網絡、數據鏈路、物理，但是按照TCP/IP分層是4層，應用、傳輸、網絡、鏈路，其實不管怎麼分，總體還是一樣只是粒度不一樣罷了，正常我們所說的主要協議是HTTP、HTTPS、TCP、IP，其中處於安全考慮，HTTP基本都被HTTPS取代了，TCP常見的三次握手、四次揮手也是重點。
後端
在講後端技術之前我們有必要先說下DNS和CDN，首先我們需要知道當我們輸入網址到頁面正常展示到底發生了什麼，第一就是域名，需要知道什麼是頂級域名、二級域名、三級域名等，如：https://www.baidu.com,其中.com就是頂級域名，baidu就是二級域名，www.指的是萬維網，其實就是我們去查域名的地方，https前面說過了。最終我們將域名解析爲具體的ip地址，然後請求返回結果，渲染頁面，但是隨着現在互聯網用戶的暴增，如果廠商只有一臺服務器在北京，全國的用戶都要請求北京這臺服務器的資源，延遲性可見一一般，這個時候CDN加速器出場了，其實就是緩存的原理，既然都訪問北京比較慢，那麼就在全國重點城市設立CDN節點，緩存北京服務器中部分數據，用戶請求的時候根據用戶ip來選擇最佳的CDN節點獲取內容，如果沒有才請求北京的資源並緩存到離用戶最近的CDN節點上，其實這個跟物流在全國各個地方建倉庫是一個道理。
好，接下來終於到了真正的後端技術了，想想都TM都有點小激動，別廢話，開整！
說到後端你敢不說Spring，我打不死你，從以前的spring+SpringMVC+某某，到現在的Spring Boot+某某，這個是生產力的提升了有沒有，什麼?沒有用過Spring+SpringMVC，看來你沒有被配置文件噁心到的前車之鑑了，終於Spring的官方也被噁心的不行了，這樣Spring Boot橫空出世，雖然也只是把原先的Spring和SpringMVC包裝了一下，但是終於不用爲了繁瑣的配置焦頭爛額了，就像Spring Boot的口號一樣“約定優於配置”。另外Spring大家族中的其他乾哥哥，親表舅的都需要看看，如Spring Cloud Netflix，涉及Eureka(服務註冊與發現)、Hystrix(容錯管理，實現斷路器模式)、Ribbon(客戶端負載均衡)、Feign(聲明式服務調用組件)、Zuul(網關，提供智能路由、訪問過濾等功能)等，Spring Cloud Config，Spring Cloud Bus，Spring Security都需要了解。
說完了Spring接下來說下負載均衡和反向代理吧，果然是符合我一貫的風格，想到哪裏說哪裏。但是在這之前需要說下服務架構的演變。
- 當網站流量很小時，只需一個應用，將所有功能都部署在一起，以減少部署節點和成本，也就是單一應用架構，用於簡化增刪改查工作量的 數據訪問框架(ORM)是瓶頸。
- 當訪問量逐漸增大，單一應用增加機器帶來的加速度越來越小，將應用拆成互不相干的幾個應用，以提升效率，形成了垂直應用架構 ，用於加速前端頁面開發的 Web框架(MVC) 是瓶頸。
- 當垂直應用越來越多，應用之間交互不可避免，將核心業務抽取出來，作爲獨立的服務，逐漸形成穩定的服務中心，使前端應用能更快速的響應多變的市場需求，這就是分佈式服務架構，用於提高業務複用及整合的 分佈式服務框架(RPC) 是瓶頸。
- 當服務越來越多，容量的評估，小服務資源的浪費等問題逐漸顯現，此時需增加一個調度中心基於訪問壓力實時管理集羣容量，提高集羣利用率，最後形成流動計算架構，用於提高機器利用率的 資源調度和治理中心(SOA) 是瓶頸。
看到了上面的服務架構演變，我們可以看到負載均衡、反向代理在所難免了，Nginx就能夠滿足這些，當然其他的也是能夠滿足的，得看你具體的業務需求了，如：Haproxy、LVS等。包括一些流量管理、安全隔離、服務容錯等知識。
接下來就是框架的核心了，不急，咋們慢慢來。
上面說服務框架演變的時候正好說到了RPC，其實就是遠程調用，通俗的話說就是調用遠程的服務就像調用本地的一樣，想想都覺得牛逼。所以dubbo/dubbox就能幫你幹這事，最初是由阿里開源，後來噹噹網在之前的基礎上做了擴展。另外springCloud也有相關的RPC組件，當然現在大公司都有自己的一套的RPC框架，但是原理都是一樣的，服務的註冊與發現。
說到服務註冊，我們就需要講講ZooKeeper了，這個組件最初是Hadoop的一個子項目，在2010年10月升級成Apache Software
Foundation(ASF)頂級項目，可見後來晉升了，地位也上去了，在分佈式協作服務方面的是一霸，另外因爲他的臨時節點可以作爲分佈式鎖的實現方式。其他的組件請自行學習，如Consul，Eureka。
註冊說完了，那麼服務之間的通信又是怎樣的呢，大家知道dubbo設計的初衷是爲了解決服務之間調用量大，傳輸數據小而生的，傳統的IO傳輸肯定不合適，那麼NIO就是很好的選擇，果然dubbo使用的NIO框架是Netty，其他的NIO框架請自行了解。
說到這裏實在有點幹舌燥，身體疲軟，但是作爲一個有韌性的當代好青年，耳邊突然響起，扶我起來，我要打十個！！！頓時一股雞血湧上頭腦，慢血復活。
哎，說到哪裏了，哦，上面說的都很正確，也沒有問題，我是誰？？？我在那兒？？？我在幹什麼？？？
可是有一個問題，假如在秒殺的時候我不能一個一個的去處理，處理完了，纔給用戶結果吧，所以就需要異步解耦，也能夠縮短我們的調用鏈，提高訪問效率。kafka、rabbitmq、rocketmq這些就映入了眼簾，其中爲分佈式而生的就是kafka，但是聽說rabbitmq更加安全的，反正都需要自行去了解，特別是消息的丟失與重複怎麼解決。
講了這麼多，終於需要訪問並存儲數據了，所以就用到了持久化框架MyBatis、Hibernate，我現在基本上都是使用MyBatis，順便說下關係型數據庫，有Oracle、MySQL/MariaDB、SQL Server、PostgrcSQL、DB2等，當然還有阿里自研的OceanBase。
隨着數據量的增大，查詢的效率也變的越來越低，而用戶也對頁面響應的要求越來越高，特別是用戶的一些熱點數據，面對這個問題我們怎麼解決呢？分佈式緩存，基於非關係型數據庫高效的訪問效率和支持高併發量的特點來完成，每次用戶的熱點數據都會先查詢非關係型數據庫，查詢不到再查詢關係型數據庫並更新緩存，目前主要使用的有Redis、Memcached，從目前的市場的使用情況來看，Redis的潛力會更大一點，它還支持數據持久化到數據庫（RDB、AOF）、分佈式鎖實現（基於lua表達式的原子性）。但是這個過程中需要考慮數據的一致性以及緩存擊穿、緩存穿透、緩存雪崩等問題。
上面說到了緩存解決了用戶請求慢的問題，但是隨着數據量的增加，單表的數據量不斷增加，特別是對於主表來說，所以分庫分表在所難免，也就是涉及到了數據遷移，這個過程中需要考慮一個主鍵重複的問題，分佈式Id是解決問題的關鍵，雪花算法瞭解一下。另外分庫分表中間件Cobar、MyCAT、TDDL、Sharding-JDBC熟悉一下。這些中間件雖然能夠幫助我們解決很多得問題，但是同時也帶來了更多的人力成本和風險，請自行領會。
都說現在的競爭其實就是流量的競爭，說的一點都不錯，看看微信、抖音、支付寶、淘寶、京東、拼多多，那個不是在搶奪流量，流量意味着數據，未來數據纔是我們的核心價值，所以市場上也出現了很多的數據販賣公司，請執法部門嚴厲打擊，絕不姑息。數據都有了，怎麼將數據轉化成有價值的信息，數據分析來了，難怪這幾年數據分析師這麼喫香。大數據分析框架也跟着喫香，從最初的hadoop，到後來的Storm、Samza、Spark、Flink。搞的我現在就想搞點數據分析一波，可是不會呀！！！
好，說完上面的知識，基本上整個大的流程都已經說完了，覺得我們可以開始搭環境、碼代碼、然後交付項目了，可是交付的過程總是困難重重，一不小心弄出一個重大事故，那可就得不償失了，你說最後這一哆嗦怪誰呢。不要怕，容器技術來了，感覺再也不慌了，心跳一下子恢復到往日的180，所以Kubernetes（k8s）、Docker你準備好了麼？？？
項目部署完成，也開始投入使用了，但是每天都是各種各樣的客訴問題，搞的人真是煩的要死，又要查日誌，我的天，你不會讓我去每一臺機器上面查找日誌吧，所以這個時候有個搜索工具是多麼的貼心呀，來吧我的小可愛，Elasticsearch，終於過上現代人的生活，其他的搜索引擎請自行了解哈，如：Solr、Apache Lucene
哎呀，剛纔上線的時候好像忘了配我的定時任務了，不慌，現在來配也來得及，關於任務調度的框架有Quartz、 elastic-job、 xxl-job，覺得哪個好用就用哪個吧，反正大公司都有自己的任務調度框架，完全不用擔心。。。
好了，關於後端部分基本說完了，但是似乎工具這塊沒說，果然我真的是想到哪裏寫到哪裏呀！！！
開發工具IDEA不用說了吧，開發神器，事半功倍，界面酷炫叼炸天，當然eclipse現在也不差，看個人吧。Git遠程倉庫管理，別說什麼svn了，還是老實用Git吧，maven版本控制工具，就是這樣簡單。Jenkins持續化集成打包工具，sonarQube代碼檢查工具，與Jenkins配合天衣無縫。一般大公司都是有自己的持續化集成和代碼檢查工具的，不用你操心。
後記
終於成功碼字碼到頸椎病犯了，但是依然強忍着疼痛，寫完這最後的倔強。可能你已經注意到我基本上寫的都是一些大的框架或者知識點，對於一些細枝末節的知識點並不涉及，比如java基礎知識，還有分佈式事務，linux的基礎知識，設計模式、JVM等這些都需要你們自己主動去研究。另外要說的一個就是再牛逼的技術也是服務於業務，沒有業務的技術就是瞎扯淡，沒有技術的業務就是一盤散沙，所以在做技術選型的時候永遠追求的是最合適的，而不是最好的。學習的過程就是由點到線，然後由線到面，最終形成知識面。祝大家好運！
本人公衆號已經開通，有興趣的可以關注一波！！！
