目錄
微服務架構的演變
這個章節主要介紹微服務架構的從單體式架構如何演變而來，介紹為什麼有這些元件側重於微服務架構的整體，簡明的表達微服務架構的全域性場景，不涉及元件以及具體如何使用各個元件等細節問題，從整體把控，全文使用辦公VIP系統為例做簡要說明（本故事純屬虛構重在理解微服務架構）。
最初的需求
由於公司成立之初人員緊張，公司裡面只有Lex作為行政人員+人事+員工+老闆，公司主要做化妝品售賣，為了滿足購買會員越來越多，如何管理問題，Lex招聘了Alex去開發一套VIP系統進行管理VIP人員，剛開始的需求非常簡單，只要能看到會員的基本資訊和購買頁面和記錄即可，所以Alex三下五除二的就搞定了這個需求。開發出了一個war包進行部署就滿足了需求。
業務發展後需要客服的問題
隨著會員的持續增加，以及網際網路的普及單一的功能已經無法滿足目前的需求，需要增加手機端的通道，新增節日的活動力度，Alex很顯然已經不能一個人同時負責這麼多業務了，於是招聘了Mike和Alex同時開發這個需求，很快他們就完成了這個專案。
隨著品牌逐漸的被人熟知，越來越多的人進行購買，資料越來越多，節日越來越多，要進行的線上促銷活動也越來越多，平臺暴露出的問題也越來越多。
- 會員管理模組出現問題後，需要將war重新開發，然後部署影響到了其他模組
- 資料越來越多，進行問題排查越來越難
- 平臺人員越來越多，平臺出現了效能瓶頸
對於這麼多問題，單一的一體式架構已經無法滿足目前的需求，急需一種全新的架構來解決這些問題
B/S和C/S架構是指的我們測試系統的架構，在工作中我們說的微服務架構或者一體式架構是針對我們的B/S或者C/S中的S（server）來進行說明的，一體式架構可以簡單理解為war包（前端和後端在一起）；而微服務是把單獨的模組進行分離，前後端進行分離來說明，對於測試來說是沒有任何感知的。因為測試過程中僅針對功能進行測試
微服務架構使用的元件
對於我們上述的問題，急需要我們進行解決，偉大的程式設計師想出了把系統進行拆分為模組單獨的模組構建為jar包而不是把所有東西都一股腦的放在一起構建為war包，本文主要描述元件的作用做簡單瞭解。
Nginx
Nginx作為反向代理器，主要處理大量使用者進行同時登入後，進行操作的負載均衡，可以把介面分發給不同伺服器進行處理從而達到均衡的效果。
Nginx的搭建相對比較簡單配置Nginx分發伺服器的地址以及前端等html存放位置即可，在使用過程中一般由運維功能師或者資深開發進行安裝和配置。
Redis
Redis主要是Key-value型高效能資料庫，彌補關係型資料庫的不足，在使用過程中儲存登入後的session等資料。
Redis分為單體模式和哨兵模式，哨兵模式可以監控Redis的多個程式，僅做了解即可工作過程中不需要測試進行搭建。
Rabbitmq
Rabbitmq作為中介軟體是進行處理大資料量的很好的中介軟體，當大量資料同時需要處理會對伺服器造成很大的衝擊這時候Rabbitmq就像清道夫一樣把所有資料進行排列處理。
Rabbitmq一般的資料量小的伺服器不需要使用，在大資料叢集中才會使用優勢才能體現，僅做簡單瞭解即可，不需要深入。
Mysql
Mysql應該是老面孔了，在微服務架構中，Mysql資料庫主要用於儲存資料，微服務為了更加徹底的分離實現初始化時，單獨對不同模組建資料庫和表的初始化指令碼，達到分庫分表的效果。
Mysql的搭建和使用只要會進行資料庫的表的資料查詢即可。
jar
jar也就是我們微服務的核心了，war需要tomcat容器進行裝載而jar自帶tomcat容器，不需要單獨安裝，單獨模組跟獨立系統一樣，可以實現不同jar包組合形成全新的系統。
jar使用會啟動即可，使用Linux命令查詢相關jar的程式即可。
jdk
jdk的作用不言而喻，使用java開發的程式碼為什麼這麼流行原因就是java的特點-write once,run anywhere,而保證這一特點的脊柱就是jdk，jdk中有jvm，所有程式碼都會在jvm中進行執行。
總結
說了這麼多，相信能對微服務有所瞭解，簡單來說微服務是為了解決網際網路普及後應用或者程式越來越複雜的問題的，從而引入了各種元件來解決這些問題，元件僅僅為我們解決問題的，所有元件對於測試來講不需要掌握做了解即可每一個元件都可以作為一個主題進行研究，並且有各種書籍作為介紹，對於測試來講核心還是掌握測試的方法和原理是根本，開發來講可能就是對jar包開發的開發人員掌握java語言，對元件也簡單瞭解，架構就要對各種元件進行深入瞭解了，這是我對微服務的理解，希望能幫助到大家，後續隨著技術的發展可能又會延伸出其他框架，需要我們保持不斷的學習。