我很熱愛技術，但確沒有機會去夢想的地方證明自己。工作快兩年了，現在在一個二線城市，基本沒有技術提升路線可言，僅僅拿着一份不高不低的工資。看着曾經的同學都去了自己夢想的地方大展拳腳，我很羨慕。雖然客觀條件有所限制，但我還是想以一個技術人的身份繼續努力下去，找回對技術的熱愛與追求，爲本就短暫的職業生涯留下點什麼。由此初衷我準備開始我的【從零開始搭建後端微服務架構】系列。雖然接觸不到互聯網，但我還是想證明，我是一名優秀的互聯網技術人。
我要搭建的系統是我曾經負責過但卻因爲合同等客觀原因流產掉的一個項目，我認爲項目非常有技術挑戰性，所以就在這裏把它實現掉。本系列着重記錄搭建的點滴歷程，我會盡可能深挖用到的每項技術，但可能並不能作爲某項技術的參考文檔（我會努力追求這一點）。
本人才疏學淺，系列文章也是憑藉自己的理論知識一步步構建，如果有不對之處希望大家可以多多指出，與我交流（qq:746411774）。
項目介紹
這個項目是爲一家醫療企業定製的數字化系統，該醫療企業號稱擁有億級的用戶羣體，整個系統設計需要滿足當前的用戶體量。新系統不但要開發新的功能，還要整合一部分老系統。整個系統有供C端用戶使用的app（類似於阿里健康，丁香醫生等），意在讓之前主打B端G端的醫療企業在C端有所作爲；有供B端使用的app，web網頁，意在讓合作伙伴能更加直觀高效的獲取信息；有供G端使用的app，web網頁，意在讓政府可以更方便的監管。話不多說，先來看我爲這個項目設計的架構規劃圖（可能涉及商業機密，已經簡略掉部分業務流程，主要突出技術架構）：
業務及技術架構介紹
cdn/負載均衡層介紹
業務層面：
根據業務方提供的信息，該公司擁有億級客戶，雖然忠實用戶只佔小部分，但也有三四百萬。流量輸入主要有兩方面：一方面是終端用戶使用終端產生的流量，另一方面是接收物聯網設備和第三方系統的數據。估算整個系統的日pv應該在一千萬左右，並且考慮到以後的增長，需要設計一個可擴展的彈性架構。
技術層面：
爲了滿足企業當前已有用戶體量和以後野蠻生長的需要，整個系統在入口層使用lvs/f5和nginx/netty搭建了二級負載均衡體系，並且採用動靜分離將靜態資源上提到cdn中，既可以減輕系統訪問壓力，也可以提升訪問速度。這種方式已經可以保證當前系統日常的穩定運行，如果出現類似於雙十一的流量激增，還可以在lvs之上加入dns動態輪詢，橫向擴展多個lvs/f5和nginx/netty二級負載均衡體系。
*：這裏使用netty主要是爲了與nginx互補，nginx主要用來做http/https請求的轉發，netty主要用來處理物聯網設備上傳的數據，在物聯網行業，總會出現很多亂七八糟的協議，這種協議用nginx並不能很好的處理，而採用netty可以更好的自定義解析方式，讓我們的系統更加靈活。由於netty只是一個高性能的通信框架，雖然性能上不輸nignx，但是在功能上確沒有nginx豐富，在代碼中再去開發一套負載均衡和轉發的邏輯會有很大的困難，所以我們這裏採用netty+rocketmq的方式，netty只管解析協議內容，解析完成之後就灌入rocketmq，由後端服務自行消費。
網關/服務層/管理系統/基礎支撐介紹
業務層面
本系統從業務層面劃分主要有一下幾個模塊：
1.樣本模塊
2.血液模塊
3.疫苗模塊
4.健康管理模塊
樣本指的是生物樣本，該企業擁有大量的生物樣本，依靠該樣本體量開展了一系列的業務，比如樣本展覽，樣本研究，樣本狀態監控等科研和產業數字化的需求；血液指的是人體血液，該公司存有一個血液庫，所涉及的業務與樣本相同，基本也是一些科研和產業數字化的需求；疫苗指的是我們平時接種的疫苗，該公司有一個疫苗庫，並且依託這個疫苗庫開展了疫苗接種的業務，該模塊的業務一方面是科研和產業數字化的需要，另一方面是直接接觸C端的疫苗預約，疫苗接種等業務；健康管理是指用戶健康管家，這也是該公司發力C端的主攻點之一，本模塊依託前面三個模塊的基礎設施，爲用戶提供健康體驗和內容服務，健康體驗比如用戶可以在app上輸入自己的體檢報告，然後app可以爲用戶提供定製化的健康管理計劃。內容服務比如提供健康小常識等。
技術層面
基於當前業務，我將4條業務線拆分成兩大類，一類是後端的管理系統用來做數據維護，另一類是服務提供組件，用來爲終端提供接口，供終端調用。而這兩大類都需要基礎服務模塊提供支持。
此外，我又從四條業務線中抽象出了兩個模塊，用戶模塊和疫苗預約模塊。
用戶模塊：由於該系統用戶基數比較大，所以單獨將用戶模塊從各個系統中抽離出來單獨形成一個微服務組件，其數據管理由平臺管理系統提供。
疫苗預約模塊：疫苗預約接種功能在其公司之前的運作當中就比較火爆，其全國有3000多個接種點，都可以支持預約、接種。高峯期的併發量比較高，所以這部分業務我單獨拆分出來形成一個微服務組件，其數據管理還是放在樣本/疫苗/血液管理系統中。
該部分主要採用springcloud技術棧去構建服務體系，內部通信採用http的方式。這裏其實在http與rpc的選擇上有些糾結，但最終還是選擇了http。說一下我的原因，dubbo相對於http來說顯得更重量級一些，雖然在很多場景下它擁有更加全面的功能，比如調用方便，自動重試，自動負載均衡等，但卻會增加系統的複雜度和耦合程度，並且在接口頻繁變動的情況下會非常笨重，我還是希望我的系統更加輕量化，所以也就在效率和易用性上做了犧牲。其負載均衡、限流、容災等特性通過springcloud的hystrix，ribbon等組件彌補。
數據層
業務層面
本系統需要提供的業務功能有：1.數據持久化 2.大數據分析 3.站內全文搜索（坑逼的需求）4.接入區塊鏈做疫苗信息溯源
技術層面
爲滿足以上的需求：
1.持久化
mysql主要用來存結構化的數據，比如用戶信息等強關係的信息
mongodb主要用來存儲物聯設備信息等，主要是保證靈活性（雖然mysql8也開始支持了json數據類型，開始朝nosql方向偏移，但是功能還很不完善，無法代替mongodb）。
2.大數據分析：
hdfs主要用來存儲大數據分析需要的數據，後面接入spark，hbase等大數據工具做用戶畫像和科研分析
3.全文搜索
使用es來做全文搜索
4.區塊鏈
這裏暫時把區塊鏈也歸爲數據層的一部分，使用以太坊作爲底層存儲
5.雖然業務沒提，但是不能忘記redis
redis用來做緩存，session共享，分佈式協調（分佈式鎖等一些亂七八糟的活）
我的任務
負責項目整體的技術流程設計、選型，爲每種業務場景設計有針對性的解決方案，保證系統安全穩定的運行。
我的設計流程
第一階段：
系統入口設計，也就是cdn，負載均衡層面的設計。
第二階段：
數據庫選型，這個階段決定數據庫層面使用何種數據庫，如何針對項目需求設計數據庫集羣方案，將業務的基礎數據庫層面的東西先打通，爲業務涉及提供支撐。
第三階段：
基礎支撐設計，比如系統中使用的mq，kafka，config等組件的設計，也是爲後面的業務設計打下基礎
第四階段：
具體業務設計，有如下兩個方面，
1.定下每個模塊中的代碼規範和設計基調。
2.對複雜或技術要求較高的業務場景做針對性分析，單個擊破。
硬件基礎
實體服務器若干臺（本身就是臆想，所以想要幾臺就要幾臺）
雲產品若干
更新頻率
由於本人技術有限，架構過程需要查閱相關資料並整理，暫定每週日晚更新一次。
下期預告
系統的總入口設計，使用lvs/f5+nginx/netty兩層負載體系打造系統入口