tob的saas平臺一般是行業應用，初期可根據團隊的特點選擇合適的開發語言和合適的架構。個人建議用php開發。租賃雲伺服器。前期做一個基礎的產品試探市場。隨著客戶的增加和需求的變化再迭代升級產品。

單詞寫錯了

sass，是css超強擴充套件語言；你應該是說 SAAS，也就是Software-as-a-Service（軟體即服務）

個人認為考慮技術選型的化，可以透過下面幾個方向去做

伺服器方式

需要考慮是使用雲伺服器、自建機房還是混合雲的方式；如果是雲服務的方式，有需要對比幾家廠商的產品服務模式和套餐

部署方式

主要有以下幾種方式可以考慮，當然可能還有更好的方式

第一種，將產品化的服務抽離出來，透過docker的方式進行部署，每個企業（客戶/使用者）獨立一個docker

第二種，服務不分離，多庫的方式進行分離

第三種，都不分離，透過企業的標示進行隔離業務資料

資料庫

技術選型初期，最好先把資料庫、快取資料庫、檔案伺服器等基礎服務選好，這樣上層的技術才好有對應的參考和對標

後端技術

可以做服務層的技術非常，java、ruby、nodejs、c#、c++等；這塊技術的選型主要考慮：

1、服務的橫行擴充套件

2、開發生態

3、團隊人員熟練度和技術本身的上手難度

4、技術框架是否成熟（文件、社群、issue數量和修復頻率）

5、日誌支援

等等

前端技術

第一：主框架

前端主要流行的是vue、react和angular；如果有專門的前端隊伍可以讓他們自己選，如果沒有，是後端兼任的化，個人建議使用vue

第二：UI庫

選擇一個好的UI庫，在後期的開發速度上會塊很多。可以針對不同的技術，去看看社群選擇合身的UI庫，例如：vue有 element-ui，iview（ViewDesign） react 有 （ant-react等）

技術文件工具

業務梳理

一、業務梳理

一般2B的業務在剛開始不會有太多的流量，前期主要是在驗證商機上，要求產品上線要快，以減少不必要的投入。在技術選型之前需要做的是針對業務的分析，規劃出平臺的業務架構。為什麼要先規劃出業務架構，你要知道重要的一點是任何的技術都是為業務服務的，脫離了業務談技術都是空中樓閣，沒有任何的意義。如果業務還沒有清楚，你要和相關人員溝通，把業務吃透，透過UML整理出符合市場要求的業務架構。

上面我們也提到在初期做的商機的驗證，不會做的大而全，而是小而可控。在商機未成熟之前，控制成本和時間，屆時船小好調頭。一般情況下在初期做的都是先滿足使用者的核心功能，然後透過不斷的迭代去滿足。技術和產品都是一樣。記住一點，技術的架構是結合業務的迭代打磨設計出來的，而不是規劃出來的。

部署方式

二、技術選型

業務架構梳理完成，要做的事情也非常的明確了，技術思路也基本上形成了。

首先是確定技術架構。技術架構可分為分散式服務和集中式服務。在初期為了滿足市場需要，一般是快字當先。技術架構可以採用集中方式架構，不要過多拆分服務，避免造成人員成本和時間成本的浪費，部署起來也非常的方便高效。強烈建議前期不要採用中臺技術模式。

第二、要考慮你的團隊人員的掌握的技術語言類別，熟悉的才是最好的，才能發揮你團隊的優勢。

第三、選取技術中介軟體，中介軟體有很多成熟點，經過考驗的，無需自己造輪子。( 中介軟體涉及快取、ORM、Web服務)。

第四、考慮你的部署方式、是否需要流量分流，因為前期是採用的集中式方式，相對來說會容易很多。

第五、如果業務發展了，得到市場的驗證，這個時候你要考慮技術架構的優化了。比如採用服務拆分(微服務)、資料庫分庫分表，NoSQL資料庫，訊息佇列等技術。如果業務不斷擴大，同時有些業務非常成熟穩定了，這個時候可以考慮中臺模式，便於可服用，快速響應市場到變化。

技術選型和產品一樣都需要一個Roadmap，按照初期、中期、長期等階段規劃符合業務發展需要的技術架構。

在網際網路技術領域，採用最多的還是Java技術，非常的成熟和穩定，支援高併發，中介軟體也相對成熟可靠。

對於目前微服務 訊息佇列 ORM等開源的中介軟體也很多，微服務有Dubbo、SpringCloud等; 訊息佇列有Kafka、RabbitMQ等；ORM使用比較多還是Mybatis。快取用的Redis.

NoSQL用的比較多的有MongoDB、Redis、HBase等。