架構？？？？
從一開始學習 JavaEE 開始，最開始聽到的便是三層架構+MVC。我認爲的架構，是整個項目的結構，由項目中的各個組件組合而成，就像是積木拼搭在一起支撐起整個體系結構，而架構的目的就是爲了解耦，以至於使用各種開發框架。
微服務
微服務是一種新型的架構風格和架構思想，從2014年開始被人們所關注。
由於互聯網發展迅速，傳統的單體架構無法承受大流量導致的高併發問題，經過這麼多年的架構演變，更多能夠支撐高併發的架構不斷出現，例如 SOA 架構（面向服務），以及微服務架構。
在我看來，微服務架構更像是 SOA 架構的昇華，相比於 SOA 架構，微服務架構從字面上更注重“微”。SOA 將服務抽取合併到同一層中（服務層），但是這並不符合“高內聚，低耦合”原則。
微服務架構能夠更好的進行分佈式系統開發，它注重的是將整體業務組件化，將單體項目按照多種拆分方式拆分成一個一個獨立的服務，每一個服務就是一個項目，可以獨立部署運行。
問題
既然微服務架構將單體應用進行拆分，單獨部署運行，那麼必然會面臨一些新型問題，這也是微服務架構需要解決的四大問題。
1.這麼多服務如何管理
將單體應用按服務拆分，通過不同程度的拆分粒度，可能拆分出幾十甚至幾百個服務。那麼，這些成百上千的服務，沒有一個統一的管理是肯定不行的，如果沒有一個管理者將其全部監控管理，那麼即使能夠部署成功，在運行過程中出現的問題也不可能發現。
2.服務如何訪問
瀏覽器訪問項目通過ip地址，但是在部署這麼多服務的情況下，每個服務的ip地址都是不相同的，我們不可能讓瀏覽器或者用戶記住每個服務的ip地址，那麼這麼多的服務要怎麼讓瀏覽器統一的訪問也是個重要的問題。
3.服務與服務之間如何通信、調用
從微服務的拆分來看，拆分出來的每個服務都是單獨獨立運行的，服務與服務之間沒有任何的關係，但是，項目中可能存在這個服務需要調用另一個服務功能，便出現了服務與服務之間相互調用的問題，應該怎麼調用纔是最好的。
4.服務崩潰怎麼辦
在高併發、大流量的情況下，服務總會有支撐不住的時候，服務宕機問題也是需要實時監控的，以便在第一時間進行修整。
我認爲，微服務架構屬於包含松耦合分佈式組件的系統結構，提供了一種新型的、更清晰的架構思想，進行項目的拆分的確很大程度的降低了項目中的耦合度問題，但是有利有弊，在降低耦合度時發生的上述四種問題也是需要解決的，如果能夠很好的解決微服務的四大問題，我覺得微服務架構在將來會有很大的發展。
以上都是作者本人在學習微服務架構過程中自我理解的，如果有誤，請指出共同進步。