套用一句廣告詞－－這是板上釘釘的事！

不過問題問得也不大對，應該是springboot＋mybatis能不能取代SSM！

SSM＝spring＋spring mvc（也有人說是struts2）＋mybatis;作為一套替代JAVA傳說中的三大框架SSH的輕量級替代品，擁有著廣大的人民群眾基礎和市場！其中spring作為容器框架，spring mvc作為控制器，分發器，模型物件的處理者，mybatis作為資料持久化框架，讀寫資料庫資料！

SSM框架曾經一度佔領著後臺伺服器的開發框架，但是配置十分繁瑣，需要額外的搭建應用伺服器等，用起來苦不堪言！在這種背景下，springboot應運而生，旨在使用超級輕量級的配置就能實現大型的分散式服務架構的目的！

看下springboot的官方定義:基於springboot構建任何事！

高階特性:springboot能讓你以最少的配置最快的時間搭建一套服務！

秒級別的spring容器初始化！

可以構建rest風格的服務，websocket，流式處理等！

構建簡單，但是十分安全！

對sql和nosql有豐富的支援！

內建tomcat和jetty讓你無需再使用war包等方式進行部署！

支援生產環境熱部署和自動重啟！

故障跟蹤和健康監控工具等等！

可以說springboot就是為了大型企業化的服務框架而生！

為什麼說springboot一定會替代SSM呢？我們看下JAVA web開發的主要框架歷程，原生開發到SSH到SSM再到springboot！一步一步都是為了徹底的實現注重業務開發，而對於資料連線，日誌列印，效能監控能實現輕開發，甚至零開發！

springboot能讓你秒級的搭建一個web伺服器！同時只需要在配置中加入簡單的mybatis連線注入就實現了原本複雜的配置檔案！

像下面這樣的幾行程式碼就得到了一個簡單的服務:

@RestController class App { @RequestMapping("/")

String home()

{ "hello" }

}

開啟安全模式:

security: basic: enabled: true user: name: secured password: foo

總之，springboot能極大的解決業務問題以外的開發問題，讓開發者能從繁雜的邊緣開發中解放出來，提高開發效率！

所以，作為JAVA程式設計師，必須快速切入到springboot和springcloud的開發中來！提高自己的生產力！

做一個關於springboot連線config，consul，mybatis，docker，druoid，hytrix等的配置和Demo，你就會明白開發原來那麼容易！

首先我認為大機率會的（我可以意會題主想表達的意思），但是這個問題又有一些怪怪的，Spring Boot和SSM也不衝突，使用Spring Boot依然可以使用Mybatis，只能說，未來會有越來越多的公司使用Spring Boot，而不是直接對SSM做整合。

SSM VS Spring Boot

先看看SSM裡面有什麼：Spring核心IOC，模組和模組之間解耦，增加程式碼的複用性，AOP面向切面程式設計； Spring MVC，輕量級的MVC框架；Mybatis ，ORM框架，直接使用SQL更容易進行掌控和調優。

而Spring Boot的出現，主要是可以很大程度上減少構建配置的工作。對於我們程式設計師來說，我們現在做一個專案的時候，不用像以前搭建SSM架構那樣，需要花時間寫大量的XML配置，而Spring Boot只需要透過註解的形式，在程式碼中配置即可。

用Spring Boot開發，究竟能有多快

繼續說說Spring Boot的優點，它到底能為開發人員提速多少呢？

Spring Boot提供了大部分主流框架的整合，提供了豐富的 Starters，整合主流開源框架，只需要進行簡單的配置就可以完成。

Spring Boot讓部署變的更加簡單，因為它本身就內嵌了應用伺服器，開發完成的程式，只需要一行命令就可以啟動，結合Docker使用效果更好。

注意，只是簡化，該寫的業務程式碼還是要寫的。

Spring Boot && 微服務（服務化）

企業級應用的一個趨勢，就是把從前一個很龐大的專案，拆分成N個獨立的服務，幾個服務配合，完成完整的業務流程。這樣做的好處是服務能力的複用，每次修改只針對一個服務進行開發，增加迭代速度。

如果一個專案依然是一個程式包，使用SSM“地獄般”的配置，忍忍也就過去了，服務釋出慢，也可以忍受，反正就一個包嘛，但是如果專案服務化，甚至微服務化了之後，這般的複雜是無法忍受的。

Spring Boot令開發速度增快，部署速度增快，所以更符合現在微服務（服務化）的趨勢。（有些公司不一定能做到微服務級別，所以我在微服務後面增加了一個說明——服務化）

spring boot能替代傳統ssm架構嗎？初看這個題目，感覺怪怪的，就我理解的spring boot和ssm在使用上完成不衝突，在特定的業務場景中，整合起來一起用，效果極佳。

為何這麼說呢？spring boot是由Pivotal團隊提供的全新框架，其設計目的是用來簡化新spring應用的初始搭建以及開發過程。該框架使用了特定的方式來進行配置，從而使開發人員不再需要定義樣板化的配置。透過這種方式，Spring Boot致力於在蓬勃發展的快速應用開發領域(rapid application development)成為領導者。而SSM（Spring+SpringMVC+MyBatis）框架集由Spring、MyBatis兩個開源框架整合而成（SpringMVC是Spring中的部分內容）。常作為資料來源較簡單的web專案的框架。從其概念就可以看出，spring boot本身還是spring,其主要在spring的配置上做了很大程度上的簡化，借用spring4的條件註解，增加了大量的預設配置，從而使專案配置啟動更加快捷簡單。而使用spring boot配置ssm框架，仍然作為許多公司的技術解決方案，得到很多程度上的使用。

據我瞭解，將spring boot和ssm放在一起比較是沒有探討價值的。更多的是，以ssm為基礎引入dubbo的分散式技術線是否會被以spring boot+spring cloud的微服務的技術線而替代的話題，討論的或許更多。這兩塊我都經歷過，也有過相關專案經歷。就我感覺而已，spring boot+spring cloud是未來的目前的發展方向，但是其大量的http請求通訊的效率問題，仍然是限制其發展的主要因素，即建議其在小規模的公司或者團隊使用，並且建議其在效能要求不高的業務場景中進行使用。而ssm依舊是經典，從之前到今後相關長的一段時間內，仍然是企業級專案開發的主流。

技術在發展，程式設計師也需要跟得上步伐，在瞭解和使用新技術的同時，要結合團隊的業務場景，要適合團隊技術線發展的主流，謹慎在線上環境中使用。簡而言之，spring boot 是框架，spring boot大體上就是：已經配置好配置檔案（取預設值）的springMVC（spring全家桶）+ 外掛版tomcat。

首先我們要理解SSM框架是什麼？SpringBoot框架又是什麼？

SSM是springmvc+spring+mybaits三大框架整合的專案，SpringBoot專案是為了省去配置檔案，把配置檔案寫在程式碼裡面的一套快速開發框架，可以說從宏觀角度來分析，springboot的應用範圍＞SSM框架，從框架角度來說，他們的底層原理是一樣的，只是springboot為了開發者快速開發整合的一套框架，springboot不僅可以整合mybaits，還可以整合jpa，jdbc等等。所以兩者的範圍不一樣，我個人理解，業務需求決定專案框架。

springboot 是一個很好的腳手架工具，不是替代原有的SSM框架，而是更好的進行敏捷開發，提高開發效率。

不存在替代問題，springboot其實就是整合各種框架，包括SSM，看你什麼組合。當然，現在開發，大多直接用SPRINGBOOT來了，不太用以前SSM方式。

Springboot和ssm側重點不同，springboot並不是為了替代ssmspringboot和ssm開發中有什麼區別？

對於普通開發而言，springboot和ssm好像並沒有太多的區別，尤其web開發過程中，基本上就是springmvc接收請求，spring做物件管理，mybatis進行資料操作，在這一層面而言，使用springboot和ssm or ssh，並沒有什麼區別

Controller層接收請求 ->service處理操作 - >dao層資料操作

但是跳轉到更上一級而言，springboot的意義就十分重大了。

springboot提供了一個“標準”

在以往的ssm架構中，根據不同架構師的理念，對於ssm的整體配置，有著不同的理解，有些架構師喜歡將html頁面，靜態檔案等等扔在一個目錄下解析，有些架構師喜歡分開目錄解析，還有些架構師喜歡在頁面後附加.do 來區分是請求controller還是靜態資源。

當然這樣做並沒有太大的問題，唯一的問題是，有沒有一個良好的標準來約束。從而減少開發人員上手時，減少閱讀配置檔案的時間?如果形成一個良好的規範，大家都遵守該規範，那麼也就不再有必要閱讀那些毫無意義卻又十分重要的配置檔案？

在springboot-starter-web中，你可以直接將靜態資源放在/static下，靜態頁面放在/public下，若是需要配置站點的icon，只需要在目錄下放置一個對應名稱的檔案即可。

若是需要連線mysql，則可以選擇對應的starter，然後根據對應starter所要求必須的配置項，在application.properties中配置即可。

而若是使用ssm架構，或許架構師會這麼做。

首先引入對應的jar包，然後處理對應的依賴，若是有衝突，則需要解決依賴衝突，解決完畢後，配置對應的配置檔案，然後再配置spring的xml。

換成springboot ，就只需要兩步，尋找starter，在application.properties配置必要引數

依賴問題由starter及springboot parent去解決，引數配置集中配置在application.properties。

這就解決了好幾個問題，首先，引數配置均在application.properties中，其次，依賴問題有starter自己解決，依賴衝突有springboot parent去解決。我們只需要關注最核心的幾個引數配置即可，而且其他人上手該專案，也只需要去關注最重要的幾個點即可，而不是在一堆xml中去查證對應配置。

由此看來，springboot和傳統的ssm的區別，則在於其提供了一個良好且有效的標準，雖然它允許你可以自由配置，但是它仍舊希望你在滿足需求的前提下，使用它的預設配置，而在目前看來，springboot的預設配置，也已經滿足了絕大多數情況下的開發要求。

對於springboot和ssm的區別，個人理解看來，springboot更像是一個應用商店，你需要什麼，你就去尋找對應的應用(starter)，並組裝完成你的需求，而ssm，則僅僅是一個簡單的應用工具，僅用於web開發領域。

SSM優缺點

1）spring 不說了，核心ioc、aop技術，ioc解耦，使得程式碼複用，可維護性大幅度提升，aop提供切面程式設計，同樣的增強了生產力。

2）spring mvc嘛，是對比struts2等mvc框架來說的，不說struts2爆出的那麼多安全漏洞，而且是類攔截，所有Action變數共享，同時是filter入口的，而spring mvc是方法攔截，controller獨享request response資料，採用的serlvet入口，與spring無縫對接。開發而言，spring mvc更加輕量和低入門。

3）mybatis嘛，看業務場景，主要是mybatis的sql可以由開發者去掌控和調優，相對hibernate等orm框架來說，更加直觀。在業務場景比較複雜，sql好多聯合關聯的情況下，mybatis誰用誰知道。當然缺點就是對sql不熟悉的開發者就不太友好了。

SSM框架和spring boot全家桶相比有哪些優缺點？

這兩者對比起來有點奇怪。因為SSM是WEB應用框架，涵蓋整個應用層，而spring boot你可以看做一個啟動、配置、快速開發的輔助框架，本身針對的是微服務。

springboot 只是為了提高開發效率，是為了提升生產力的：

1、springboot一個應用是一個可執行jar（啟動類main方法啟動web應用），而不像傳統的war，內嵌tomcat容器，可以jar形式啟動一個服務，可以快速部署釋出web服務，微服務最好不過了。

2、將原有的xml配置，簡化為java配置

3、當然結構可能跟一般的ssm有一定區別，但其實主要是在資原始檔。

Spring Boot 預設“約定”從資源目錄的這些子目錄讀取靜態資源：

src/main/resources/META-INF/resourcessrc/main/resources/static （推薦）src/main/resources/public

所以，springboot的產生並不是為了替代ssm，並不侷限於web開發，它透過約定大約配置原則，讓開發效率進一步提高，透過springboot開發會很方便，和SSM框架相比，大家會更傾向於springboot

“替代”感覺談不上，只能說是不同時期的產物。

換做5年前甚至7年前，SSM確實很流行，三大框架進行整合，Spring做裝載bean的容器，Struts2做頁面跳轉邏輯，Mybatis做ORM框架，頁面用的JSP，所有的一切看起來非常完美。

隨著網際網路的技術迭代以及使用者數量的增長，原來的一些傳統專案在高負載和高併發的場景下顯得越來越吃力，慢慢的人們開始考慮頁面靜態化（FreeMarker）和快取（Memcache）等技術使得專案能夠滿足實際場景需求。

隨著網際網路元件的成熟以及阿里雙十一的技術落地推廣，才使得一些現在常用的技術得以展現在大眾的視野面前，如Redis、MQ、Dubbo、Kafka、Springcloud全家桶等，上面所提及的這些技術，都是在某一場景下表現優秀進而被大家所熟知的。

每一種技術的產生都是為了解決當前所遇到的一些問題，都是時代的產物。

仔細分析下Springboot，其底層還是Spring，在Spring Java配置的基礎上開發了自動化配置，這也屬於時代的產物，為了迎合那些比較懶的程式設計師，透過簡簡單的配置就可以達到之前需要大量配置才能達到的效果。

總結一句：“替代”感覺談不上，只能說是不同時期的產物！