溫馨提示：本文適合初，中級水平。如果是面試高階需要多瞭解一下多執行緒高併發以及底層原理原始碼等知識。

AOP與IOC的概念（即spring的核心）

a) IOC：Spring是開源框架，使用框架可以使我們減少工作量，提高工作效率並且它是分層結構，即相對應的層處理對應的業務邏輯，減少程式碼的耦合度。而spring的核心是IOC控制反轉和AOP面向切面程式設計。IOC控制反轉主要強調的是程式之間的關係是由容器控制的，容器控制物件，控制了對外部資源的獲取。而反轉即為，在傳統的程式設計中都是由我們建立物件獲取依賴物件，而在IOC中是容器幫我們建立物件並注入依賴物件，正是容器幫我們查詢和注入物件，物件是被獲取，所以叫反轉。

b) AOP：面向切面程式設計，主要是管理系統層的業務，比如日誌，許可權，事物等。AOP是將封裝好的物件剖開，找出其中對多個物件產生影響的公共行為，並將其封裝為一個可重用的模組，這個模組被命名為切面（aspect），切面將那些與業務邏輯無關，卻被業務模組共同呼叫的邏輯提取並封裝起來，減少了系統中的重複程式碼，降低了模組間的耦合度，同時提高了系統的可維護性。

溫馨提示：可以研究一下AOP切面程式設計方法，以及切入點等。

設計模式知道有哪些？
單例模式
優點：
只有一個例項，減少了記憶體開支；
可以避免對系統資源的多重佔用；
可以在系統中設定全域性的訪問點，優化和共享資源訪問；
缺點：
沒有介面，擴充套件困難；
對測試開發不利；
應用場景：
要求生成唯一序列號的場景；
需要一個共享訪問點；
建立一個物件需要消耗過多的資源時
需要定義大量的靜態常量和靜態方法時（也可直接宣告為static的方式）；

工廠方法模式
優點：
良好的封裝性，程式碼結構清晰；
擴充套件非常好；
遮蔽產品類；
應用場景：
是new一個物件的替代品；
需要靈活的，可擴充套件的框架時；
使用在測試驅動開發的框架下；

抽象工廠模式
優點：
封裝性；
產品族內部的約束為非公開狀態；
缺點：
產品族擴充套件困難；

溫馨提示：面試的時候一般會問專案中那裡用到了這些模式，請舉例說一下實現了什麼功能等。

cookie和 session的區別：
 --1.cookie資料存放在客戶的瀏覽器，session資料放在伺服器上。
 --2.cookie不是很安全，別人可以分析存放本地的cookie並行cookie欺騙考慮到安全應當使用session。
 --3.session會在一定時間內儲存在伺服器上。當訪問增多，會比較佔用你伺服器的效能考慮到減輕伺服器效能，應當使用cookie。
 --4.單個cookie儲存的資料不能超過4K，很多瀏覽器都限制一個站點最多儲存20個cookie。
 --5.個人建議：將登陸資訊存放為session 其他資訊如果需要保留，可以放在cookie中

final和finally和finalize的區別：
final是全域性變數宣告的時候使用，意思是這個變數不可被修改，不可被override，一般用於宣告常量，或者系統設定的值。
finally是在try-catch-finally塊中配套使用，作用是，不管程式碼執行了try還是catch，最後一定會執行finally裡面的程式碼
finalize是召喚垃圾收集器的命令，使用後，系統就安排一次垃圾回收
但是不是立即執行，執行的時間點是無法確定的。
沒有特別的要求的話一般不需要使用finalize，交給gc自己管理就好。

JAVA虛擬機器瞭解嗎？

JAVA的JVM的記憶體可分為3個區：堆(heap)、棧(stack)和方法區(method)堆區:
1.儲存的全部是物件，每個物件都包含一個與之對應的class的資訊。(class的目的是得到操作指令)
2.jvm只有一個堆區(heap)被所有執行緒共享，堆中不存放基本型別和物件引用，只存放物件本身
棧區:
1.每個執行緒包含一個棧區，棧中只儲存基礎資料型別的物件和自定義物件的引用(不是物件)，物件都存放在堆區中
2.每個棧中的資料(原始型別和物件引用)都是私有的，其他棧不能訪問。
3.棧分為3個部分：基本型別變數區、執行環境上下文、操作指令區(存放操作指令)。
方法區:
1.又叫靜態區，跟堆一樣，被所有的執行緒共享。方法區包含所有的class和static變數。
2.方法區中包含的都是在整個程式中永遠唯一的元素，如class，static變數。

溫馨提示：筆試的時候可能會讓你畫Java虛擬機器機構圖。這個就不是單單的JVM的記憶體圖了。

下圖是JAVA虛擬機器的結構圖：

java既然存在gc執行緒，為什麼還存在記憶體洩漏？
  答：無論哪種語言的記憶體分配方式，都需要返回分配記憶體的真實地址，Java中物件通過new關鍵字或反射建立物件，存放在堆中，所有物件的回收都是由Java虛擬機器通過垃圾回收機制完成的，GC會檢測長時間沒有使用的物件進行回收，但是像一些靜態欄位、靜態引用類、資料庫的連線、網路連線等，若沒有正確處理，還是會造成記憶體洩漏。

java記憶體洩漏的根本原因是？
  答：記憶體物件明明已經不需要的時候，還仍然保留著這塊記憶體和它的訪問方式（引用）。
如何避免記憶體洩漏？
  答：明確引用變數的生命週期，是方法內部的區域性變數，還是類例項變數，與類例項生命週期相同的要宣告為例項變數。
要避免這種情況下的記憶體洩露，要求我們以C/C++ 的記憶體管理思維來管理自己分配的記憶體。第一，是在宣告物件引用之前，明確記憶體物件的有效作用域。在一個函式內有效的記憶體物件，應該宣告為 local 變數，與類例項生命週期相同的要宣告為例項變數……以此類推。第二，在記憶體物件不再需要時，記得手動將其引用置空。

hashMap 原理？為什麼是執行緒不安全的，底層是用什麼實現的？。
   答：在JDK1.6，JDK1.7中，HashMap採用位桶（類似陣列）+連結串列實現，即使用連結串列處理衝突，同一hash值的連結串列都儲存在一個連結串列裡。但是當位於一個桶中的元素較多，即hash值相等的元素較多時，通過key值依次查詢的效率較低。而JDK1.8中，HashMap採用位桶+連結串列+紅黑樹實現，當連結串列長度超過閾值（8）時，將連結串列轉換為紅黑樹，這樣大大減少了查詢時間。

在java jdk8中對HashMap的原始碼進行了優化，在jdk7中，HashMap處理“碰撞”的時候，都是採用連結串列來儲存，當碰撞的結點很多時，查詢時間是O（n）。
在jdk8中，HashMap處理“碰撞”增加了紅黑樹這種資料結構，當碰撞結點較少時，採用連結串列儲存，當較大時（>8個），採用紅黑樹
（特點是查詢時間是O（logn））儲存（有一個閥值控制，大於閥值(8個)，將連結串列儲存轉換成紅黑樹儲存）

hashmap底層實現方法不是同步的，
HashMap在併發執行put操作時會引起死迴圈（兩個put的key發生了碰撞(hash值一樣)，那麼根據HashMap的實現，這兩個key會新增到陣列的同一個位置，這樣最終就會發生其中一個執行緒的put的資料被覆蓋），導致CPU利用率接近100%。因為多執行緒會導致HashMap的Node連結串列形成環形資料結構，一旦形成環形資料結構，
Node的next節點永遠不為空，就會在獲取Node時產生死迴圈。（發生多個執行緒同時對Node陣列進行擴容，都在重新計算元素位置以及複製資料，但是最終只有一個執行緒擴容後的陣列會賦給table，也就是說其他執行緒的都會丟失，並且各自執行緒put的資料也丟失）

解決hash衝突的辦法？
Java中hashmap的解決辦法就是採用的鏈地址法。

HashMap，Hashtable，ConcurrentHashMap和synchronized Map的原理和區別。
   答：HashMap不是執行緒安全的；Hashtable執行緒安全，但效率低，因為是Hashtable是使用synchronized的，所有執行緒競爭同一把鎖；而ConcurrentHashMap不僅執行緒安全而且效率高，因為它包含一個segment陣列，將資料分段儲存，給每一段資料配一把鎖，也就是所謂的鎖分段技術。

JDK1.8在JDK1.7的基礎上針對一個鏈上資料過多（即拉鍊過長的情況）導致效能下降，增加了紅黑樹來進行優化。即當連結串列超過8時，連結串列就轉換為紅黑樹，利用紅黑樹快速增刪改查的特點提高HashMap的效能，其中會用到紅黑樹的插入、刪除、查詢等演算法。

ArrayList和 LinkedList的區別？
   ArrayList實現了List介面,它是以陣列的方式來實現的,陣列的特性是可以使用索引的方式來快速定位物件的位置,因此對於快速的隨機取得物件的需求,使用ArrayList實現執行效率上會比較好. 
   LinkedList是採用連結串列的方式來實現List介面的,它本身有自己特定的方法，如: addFirst(),addLast(),getFirst(),removeFirst()等. 由於是採用連結串列實現的,因此在進行insert和remove動作時在效率上要比ArrayList要好得多!適合用來實現Stack(堆疊)與Queue(佇列),前者先進後出，後者是先進先出.

ArrayList

      優點：適合隨機讀取的時候，讀取速度快，可以一步get(index)。

　　缺點：新增值很慢——一方面，新增資料在array中間的時候，需要移動後面的數；另一方面，當長度大於初始長度的時候，每新增一個數，都會需要擴容。

LinkedList：雙向連結串列

　　優點：新增，刪除很快——新增在list中間也只需要更改指標；長度不固定。
實現棧和佇列方面，LinkedList要優於ArrayList。
 

理論經典：TCP協議的3次握手與4次揮手過程詳解。傳輸的報文格式是什麼？
       （A）URG：緊急指標（urgent pointer）有效。
       （B）ACK：確認序號有效。
       （C）PSH：接收方應該儘快將這個報文交給應用層。
       （D）RST：重置連線。
       （E）SYN：發起一個新連線。
       （F）FIN：釋放一個連線。

（1）第一次握手：
Client將標誌位SYN置為1，隨機產生一個值seq=J，並將該資料包傳送給Server，Client進入SYN_SENT狀態，等待Server確認。

（2）第二次握手：
Server收到資料包後由標誌位SYN=1知道Client請求建立連線，Server將標誌位SYN和ACK都置為1，ack=J+1，隨機產生一個值seq=K，並將該資料包傳送給Client以確認連線請求，Server進入SYN_RCVD狀態。

（3）第三次握手：
Client收到確認後，檢查ack是否為J+1，ACK是否為1，如果正確則將標誌位ACK置為1，ack=K+1，並將該資料包傳送給Server，Server檢查ack是否為K+1，ACK是否為1，如果正確則連線建立成功，Client和Server進入ESTABLISHED狀態，完成三次握手，隨後Client與Server之間可以開始傳輸資料了。

SYN攻擊：

在三次握手過程中，Server傳送SYN-ACK之後，收到Client的ACK之前的TCP連線稱為半連線（half-open connect），此時Server處於SYN_RCVD狀態，當收到ACK後，Server轉入ESTABLISHED狀態。SYN攻擊就是Client在短時間內偽造大量不存在的IP地址，並向Server不斷地傳送SYN包，Server回覆確認包，並等待Client的確認，由於源地址是不存在的，因此，Server需要不斷重發直至超時，這些偽造的SYN包將產時間佔用未連線佇列，導致正常的SYN請求因為佇列滿而被丟棄，從而引起網路堵塞甚至系統癱瘓。SYN攻擊時一種典型的DDOS攻擊，檢測SYN攻擊的方式非常簡單，即當Server上有大量半連線狀態且源IP地址是隨機的，則可以斷定遭到SYN攻擊了，使用如下命令可以讓之現行：

#netstat -nap | grep SYN_RECV

第一次揮手：
Client傳送一個FIN，用來關閉Client到Server的資料傳送，Client進入FIN_WAIT_1狀態。
第二次揮手：
Server收到FIN後，傳送一個ACK給Client，確認序號為收到序號+1（與SYN相同，一個FIN佔用一個序號），Server進入CLOSE_WAIT狀態。
第三次揮手：
Server傳送一個FIN，用來關閉Server到Client的資料傳送，Server進入LAST_ACK狀態。
第四次揮手：
Client收到FIN後，Client進入TIME_WAIT狀態，接著傳送一個ACK給Server，確認序號為收到序號+1，Server進入CLOSED狀態，完成四次揮手。

請寫出JDBC連線資料庫的程式碼。
//1.載入驅動
Calss.forName("com.mysql.jdbc.driver");
//建立資料庫連線物件
Connection conn = DriverManager.getConnection(url,user,password)

Threadlocal的作用？
    ThreadLocal是解決執行緒安全問題一個很好的思路，它通過為每個執行緒提供一個獨立的變數副本解決了變數併發訪問的衝突問題。在很多情況下， ThreadLocal比直接使用synchronized同步機制解決執行緒安全問題更簡單，更方便，且結果程式擁有更高的併發性。

Synchronized用於執行緒間的資料共享，而ThreadLocal則用於執行緒間的資料隔離。

ThreadLocal和Synchonized都用於解決多執行緒併發訪問題。但是ThreadLocal與synchronized有本質的區別:
    synchronized是利用鎖的機制，使變數或程式碼塊在某一時該只能被一個執行緒訪問。而ThreadLocal為每一個執行緒都提供了變數的副本，使得每個執行緒在某一時間訪問到的並不是同一個物件，這樣就隔離了多個執行緒對資料的資料共享。而Synchronized卻正好相反，它用於在多個執行緒間通訊時能夠獲得資料共享。

什麼情況下索引失效？

1.對查詢進行優化，要儘量避免全表掃描，首先應考慮在 where 及 order by 涉及的列上建立索引。

2.應儘量避免在 where 子句中對欄位進行 null 值判斷，否則將導致引擎放棄使用索引而進行全表掃描，如：select id from t where num is null

3.應儘量避免在 where 子句中使用 != 或 <> 操作符，否則將引擎放棄使用索引而進行全表掃描。

4.應儘量避免在 where 子句中使用 or 來連線條件，如果一個欄位有索引，一個欄位沒有索引，將導致引擎放棄使用索引而進行全表掃描，如：

select id from t where num=10 or Name = 'admin'

高資料併發下的資料安全： 
1、悲觀鎖，鎖住資料庫。但是這種不太好，在高併發下，會因為請求太多被阻塞而使得系統陷入異常。
2、佇列的思想。將請求都放入佇列中，先進的先出嘛。問題是，當高併發的時候，一瞬間佇列空間會被撐爆。或者說，因為佇列太大，最終處理時間還是會變長。這兩種情況都會導致系統異常。
3、樂觀鎖：比較適合。當資料來訪問的時候，都可以修改資料，但是給加上version，只有在version最前的時候，最終才能夠執行成功，其他的使用者回滾。

儘量將請求攔截在系統上游

讀多寫少的常用多使用快取

String、StringBuffer與StringBuilder之間區別？
   答：String的值是不可變的，每次操作都會產生新的String物件。線上程安全上，StringBuilder是執行緒不安全的，效率高，是可變的字串序列。而StringBuffer是執行緒安全的，效率低，是可變的字串序列,有一定的緩衝區，當字串大小沒有超過容量時，不會產生新的物件。
String：適用於少量的字串操作的情況，
StringBuilder：適用於單執行緒下在字元緩衝區進行大量操作的情況，
StringBuffer：適用多執行緒下在字元緩衝區進行大量操作的情況。

　　
執行緒的生命週期？

新建 ：從新建一個執行緒物件到程式start() 這個執行緒之間的狀態，都是新建狀態；
就緒 ：執行緒物件呼叫start()方法後，就處於就緒狀態，等到JVM裡的執行緒排程器的排程；
執行 ：就緒狀態下的執行緒在獲取CPU資源後就可以執行run(),此時的執行緒便處於執行狀態，執行狀態的執行緒可變為就緒、阻塞及死亡三種狀態。
等待/阻塞/睡眠 ：在一個執行緒執行了sleep（睡眠）、suspend（掛起）等方法後會失去所佔有的資源，從而進入阻塞狀態，在睡眠結束後可重新進入就緒狀態。
終止 ：run（）方法完成後或發生其他終止條件時就會切換到終止狀態。

資料庫的優化？
    如：資料庫叢集，分表分庫，讀寫分離，新增索引，適當新增冗餘欄位，儘量單表操作，少使用*查詢等等。

請寫出一個考慮併發安全的單例？
public class MySingleton {
    
    private static MySingleton instance = null;
    
    private MySingleton(){}
    
    public synchronized  static MySingleton getInstance() {
        if(instance == null){//懶漢式
            instance = new MySingleton();
        }
        return instance;
    }
}

-------------------------------------------------------------------------------------------------------------------------------------------------------------------------

以下是spring Cloud微服務的相關問題。面試的時候可以在網上找一下相關視訊看看，會spring Cloud的會有優勢。現在新專案一般都採用spring Cloud開發。以前開發的專案一般是分散式的採用Dubbo。但很小的專案一般也用不上，哈哈！
什麼是微服務？
   答：微服務架構是一種架構模式或者說是一種架構風格，它提倡將單一應用程式劃分為一組小的服務，每個服務執行在獨立的自己
程序中，服務之間相互協調、配合，為使用者提供最終價值。
     或者說微服務化的核心就是將傳統的一站式應用，根據業拆分成一個一個的服務，徹底地去耦合，每一個微服務提供單一業務功能的服務，
一個服務做一件事，從技術角度看就是一種小而獨立的處理過程，類似程序概念，能夠自行單獨啟動或者銷燬，擁有自己獨立的資料庫。

spring Cloud和Dubbo有哪些區別？
    答：本質區別是通訊機制不一樣。Dubbo 基於RPC遠端過程呼叫，spring Cloud是基於HTTP的restful apl（REST API）呼叫。

微服務的優缺點分別是什麼？說一下你在專案中遇到的坑？
  答：Martin Fowler對 微服務架構 的描述中，雖然該架構相較於單體架構有模組化解耦、可獨立部署、技術多樣性等諸多優點，
但是由於分散式環境下解耦，也帶出了不少測試與運維複雜度。
   優點：每個服務足夠內聚，足夠小，程式碼容易理解這樣能聚焦一個指定的業務功能或者業務需求
   開發簡單、開發效率提高、一個服務可能就是專一的只幹一件事
   微服務能夠被小團隊單獨開發，這個小團隊是2-5人左右的開發人員組成
   微服務是鬆藕合的，是有功能意義的服務，無論是在開發階段或者部署階段都是獨立的
   微服務能使用不同的語言開發
   易於和第三方整合，微服務允許容易且靈活的方式整合自動部署，通過持續整合工具，如：jenkins,Hudson,bamboo
   微服務易於被一個開發人員理解，修改和維護，這樣小團隊能夠更關注自己的工作成果。無需通過合作才能體現價值
   微服務允許你利用融合最新技術
   微服務只是業務邏輯程式碼，不會和HTML，CSS或者其他介面元件混合
   每個微服務都有自己的儲存能力，可以有自己的資料庫。也可以有統一的資料庫
    缺點：開發人員要處理分散式系統的複雜性
    多服務運維難度，隨著服務的增加，運維的壓力也在增大
    系統部署依賴
    服務間通訊成本
    資料一致性
    系統整合測試
    效能監控。。。。

傳統的ACID分別是什麼？
   答：A（Atomicity）原子性 C（Consistency）一致性 I（Isolation）獨立性 D（Durability）永續性
CAP是什麼？
   答：C（Consistency）強一致性 A（Availability）可用性 P(Partition tolerance)分割槽容錯性

eureka和zookeeper都可以提供服務註冊與發現的功能，請說說兩個的區別？
   答：著名的CAP理論指出，一個分散式系統不可能同時滿足C（一致性）、A（可用性）、P（分割槽容錯性）。
由於分割槽容錯性P在分散式系統中必須要保證的，因此我們只能在A和C之間進行權衡。
   因此Zookeeper保證的是CP，Eureka則是AP。

   Zookeeper保證的是CP：當向註冊中心查詢服務列表時，我們可以容忍註冊中心返回的是幾分鐘以前的註冊資訊，但不能接受服務直接down掉不可用。
也就是說，服務註冊功能對可用性的要求要高於一致性。但是zk會出現這樣一種情況，當master節點因為網路故障與其他節點失去聯絡時，剩下節點會重新
進行leader選舉。問題在於，選舉leader的時間太長，30-120s,且選舉期間整個zk叢集都是不可用的，這就導致在選舉期間註冊服務癱瘓。在雲部署壞境下，
因網路問題使得zk叢集失去master節點是較大的概率會發生的事，雖然服務能夠最終恢復，但是漫長的選舉時間導致註冊長期不可用是不能容忍的。
  Eureka保證AP：設計時就優先保證可用性。Eureka各個節點都是平等的，幾個節點掛掉不會影響正常節點工作，剩餘的節點依然可以提供註冊和查詢服務。
而Eureka的客戶端在向某個Eureka註冊或時如果發現連線失敗，則會自動切換至其它節點，只要有一臺Eureka還在，就能保證註冊服務可用（保證可用性），
只不過查到的資訊可能不是最新的（不保證強一致性）。除此之外，eureka還有一種自我保護機制，如果在15反正內超過85%的節點都沒有正常的心跳，那麼
Eureka就認為客戶端與註冊中心出現了網路故障，此時會出現以下幾種情況：
  1.Eureka不再從註冊列表中移除因為長時間沒收到心跳而應該過期的服務
  2.Eureka仍然能夠接受新服務的註冊和查詢請求，但是不會被同步到其它節點上（即保證當前節點依然可用）
  3.當網路穩定時，當前例項新的註冊資訊會被同步到其它節點中

  因此，Eureka可以很好的應對因網路故障導致部分節點失去聯絡的情況，而不會像zookeeper那樣使整個註冊服務癱瘓。

Ribbon是什麼？怎麼實現的？
   答：Spring Cloud Ribbon是基於Netflix Ribbon實現的一套客戶端 負載均衡的工具。對ConfigBean使用註解@LoadBalanced實現的，有輪詢演算法，隨機演算法，時間加權演算法，重試演算法等等。預設是輪詢演算法。需要修改的話在ConfigBean中選擇相應的演算法。一般使用RetryRule演算法。因為服務正常的情況先先按RoundRobinRule(輪詢策略)，如果獲取服務失敗則在指定時間內會進行重試，獲取可用的服務。也可以自己定義策略。在主啟動類上加@RibbonClient(name="微服務名"，configuration=策略自定義類名.class)，策略自定義類不能放在@ComponentScan掃描當前包下以及子包下（不能主啟動類包下面）。

Feign是一個宣告式的Web服務客戶端，使得編寫Web服務客戶端變得非常容易。只需要建立一個介面，然後在上面添加註解即可。
Feign可以與Eureka和Ribbon組合使用以支援負載均衡。

hystrix是一個用於處理分散式系統的延遲和容錯的開源庫，在分散式系統裡，許多依賴不可避免的會呼叫失敗，比如超時、異常等待，hystrix能夠保證在一個依賴出現問題的情況下，不會導致整體服務失敗，避免級聯故障，以提供分散式系統的彈性。
hystrix能夠進行服務降級，服務熔斷，服務限流，接近實時的監控。

什麼是服務熔斷？什麼是服務降級？
    答：服務熔斷一般是指軟體系統中，由於某些原因使得服務出現了過載現象，為防止造成整個系統故障，從而採用的一種保護措施，所以很多地方把熔斷亦稱為過載保護。
    觸發原因不太一樣，服務熔斷一般是某個服務（下游服務）故障引起，而服務降級一般是從整體負荷考慮；
    管理目標的層次不太一樣，熔斷其實是一個框架級的處理，每個微服務都需要（無層級之分），而降級一般需要對業務有層級之分（比如降級一般是從最外圍服務開始）

服務監控有什麼作用？
   答：使用hystrixDashboard技術快速發現故障例項和高壓力例項。

使用zuul技術對訪問真實路徑進行保護，使用虛地址訪問。

引入新技術的步驟？
  答：第一步，pom.xml中新增依賴座標。第二步，在主啟動類新增啟動註解@EnableXXX.如@EnableEurekaClient

如何搭建微服務架構？
  答：整套開發技術棧以SpringCloud為主，單個微服務模組以SpringMVC+SpringBoot/Spring+Mybatis組合進行開發
      前端層，頁面H5 +thymeleaf/樣式CSS3+Bootstrap/前端框架JQuery+Node|vue等
      負載層，前端訪問通過Http或者Https協議到達服務端的LB，可以是F5等硬體做負載均衡，還可以自行部署LVS+Keepalived等（前期量小可以直接使用Nginx）
      閘道器層，請求通過LB後，會到達整個微服務體系的閘道器層Zuul(Gateway),內嵌Ribbon做客戶端負載均衡，Hystrix做熔斷降級等
      服務註冊，採用Eureka來做服務治理，Zuul會從Eureka叢集獲取已釋出的微服務訪問地址，然後根據配置把請求代理到相應的微服務去
      docker容器，所有的微服務模組都部署在Docker容器裡面，而且前後端服務完全分開，各自獨立部署後前端微服務呼叫後端微服務，後端微服務之間會有相互呼叫
      服務呼叫，微服務模組間呼叫都採用標準的Http/Https+REST+JSON的方式，呼叫技術採用Feign+HttpClient+Ribbon+Hystrix
      統一配置，每個微服務模組會跟Eureka叢集、配置中心（SpringCloudConfig）等進行互動
      第3方框架，每個微服務模組根據實現的需要，通常還需要使用一些第三方框架，比如常用的有：快取服務（Redis）、圖片服務（FastDFS）、搜尋服務（ElasticSearch）、安全管理（shiro）等等
      Mysql資料庫，可以按照微服務模組進行拆分，統一訪問公共庫或者單獨自己庫，可以單獨構建Mysql叢集或者分庫分表MyCat等。

如果你是湖南的歡迎加入湖南人在深圳-Java群：557651502