美團採用什麼web伺服器

1. web伺服器類型介紹

web應用的運營都是基於web伺服器的存在才能實現的。今天我們就一起來了解一下，目宴帶前比較常見的一些web伺服器都有哪些類型。

1、Tomcat伺服器

目前非常流行的Tomcat伺服器是Apache-Jarkarta開源項目中的一個子項目，是一個小型、輕量級的支持JSP和Servlet技術的Web伺服器，也是初學者學習開發JSP應用的選。

2、Resin伺服器

Resin是Caucho公司的產品，是一個非常流行的支持Servlet和JSP的伺服器，速度非常快。Resin本身包含了一個支持HTML的Web伺服器，這使它不僅可以顯示動態內容，而且顯示靜態內容的能力也毫不遜色，因此許多網站都是使用Resin伺服器構建

3、JBoss伺服器

JBoss是一個種遵從javaEE規范的、開放源代碼的、純Java的EJB伺服器，對於J2EE有很好的支持。JBoss採用JMLAPI實現軟體模塊的集成與管理，其核心服務又是提供EJB伺服器，不包含Servlet和JSP的Web容器，不過它可以和Tomcat完美結合

4、WebSphere伺服器

WebSphere是IBM公司的產品，可進一步細分為WebSpherePerformancePack、CacheManager和WebSphereApplicationServer等系列，其中WebSphereApplicationServer是基於Java的應用環境，可以運行於SunSolaris、WindowsNT等多種操作系統平台，用於建立、部署和管理Internet和IntranetWeb應用程序。

5、WebLogic伺服器

WebLogic是BEA公司的產品(現在已經被Oracle收購)，可進一步細分為WebLogicServer、WebLogicEnterprise和WebLogicPortal等系列，其中WebLogicServer的功能特別強大。WebLogic支持企業級的、多層次的和完全分布式的Web應用，並且伺服器的配置簡單、界面友好。IT培訓http://www.kmbdqn.cn/認慧祥春為對於那些正在尋求能夠提供Java平台所前耐擁有的一切應用伺服器的用戶來說，WebLogic是一個十分理想的選擇。

2. 美團面試題：如何設計負載均衡架構支撐千萬級用戶的高並發訪問

1.1 負載均衡介紹

1.1.1 負載均衡的妙用

1.1.2 為什麼要用lvs

那為什麼要用lvs呢？

ü 簡單一句話，當並發超過了Nginx上限，就可以使用LVS了。

ü 日1000-2000W PV或並發請求1萬以下都可以考慮用Nginx。

ü 大型門戶網站，電商網站需要用到LVS。

1.2 LVS介紹

LVS是linux Virtual Server的簡寫，意即Linux虛擬伺服器，是一個虛擬的伺服器集群系統，可以在UNIX/LINUX平台下實現負載均衡集群功能。該項目在1998年5月由章文嵩博士組織成立，是 中國國內最早出現的自由軟體項目之一 。

1.2.1 相關參考資料

LVS官網： http://www.linuxvirtualserver.org/index.html

相關中文資料

1.2.2 LVS內核模塊ip_vs介紹

ü LVS無需安裝

ü 安裝的是管理工具，第一種叫ipvsadm，第二種叫keepalive

ü ipvsadm是通過命令行管理，而keepalive讀取配置文件管理

ü 後面我們會用Shell腳本實現keepalive的功能

1.3 LVS集群搭建

1.3.1 集群環境說明

主機說明

web環境說明

web伺服器的搭建參照：

Tomcat：

http://www.cnblogs.com/clsn/p/7904611.html

Nginx：

http://www.cnblogs.com/clsn/p/7750615.html

1.3.2 安裝ipvsadm管理工具

安裝管理工具

查看當前LVS狀態，順便激活LVS內核模塊。

查看系統的LVS模塊。

1.3.3 LVS集群搭建

命令集 ：

檢查結果 ：

ipvsadm參數說明： (更多參照 man ipvsadm)

1.3.4 在web瀏覽器配置操作

命令集 ：

至此LVS集群配置完畢 ！

1.3.5 進行訪問測試

瀏覽器訪問：

命令行測試：

抓包查看結果：

arp解析查看：

1.4 負載均衡（LVS）相關名詞

術語說明：

1.4.1 LVS集群的工作模式--DR直接路由模式

DR模式是通過改寫請求報文的目標MAC地址，將請求發給真實伺服器的，而真實伺服器將響應後的處理結果直接返回給客戶端用戶。

DR技術可極大地提高集群系統的伸縮性吵拆昌。但要求調度器LB與真實伺服器RS都有一塊物理升扒網卡連在同一物理網段上，即必須在同一區域網環境。

DR直接路由模式說明：

a)通過在調度御攜器LB上修改數據包的目的MAC地址實現轉發。注意，源IP地址仍然是CIP，目的IP地址仍然是VIP。

b)請求的報文經過調度器，而RS響應處理後的報文無需經過調度器LB，因此，並發訪問量大時使用效率很高，比Nginx代理模式強於此處。

c)因DR模式是通過MAC地址的改寫機制實現轉發的，因此，所有RS節點和調度器LB只能在同一個區域網中。需要注意RS節點的VIP的綁定(lo:vip/32)和ARP抑制問題。

d)強調一下：RS節點的默認網關不需要是調度器LB的DIP，而應該直接是IDC機房分配的上級路由器的IP(這是RS帶有外網IP地址的情況)，理論上講，只要RS可以出網即可，不需要必須配置外網IP，但走自己的網關，那網關就成為瓶頸了。

e)由於DR模式的調度器僅進行了目的MAC地址的改寫，因此，調度器LB無法改變請求報文的目的埠。LVS DR模式的辦公室在二層數據鏈路層（MAC），NAT模式則工作在三層網路層（IP）和四層傳輸層（埠）。

f)當前，調度器LB支持幾乎所有UNIX、Linux系統，但不支持windows系統。真實伺服器RS節點可以是windows系統。

g)總之，DR模式效率很高，但是配置也較麻煩。因此，訪問量不是特別大的公司可以用haproxy/Nginx取代之。這符合運維的原則：簡單、易用、高效。日1000-2000W PV或並發請求1萬以下都可以考慮用haproxy/Nginx(LVS的NAT模式)

h)直接對外的訪問業務，例如web服務做RS節點，RS最好用公網IP地址。如果不直接對外的業務，例如：Mysql，存儲系統RS節點，最好只用內部IP地址。

DR的實現原理和數據包的改變

(a) 當用戶請求到達Director Server，此時請求的數據報文會先到內核空間的PREROUTING鏈。 此時報文的源IP為CIP，目標IP為VIP

(b) PREROUTING檢查發現數據包的目標IP是本機，將數據包送至INPUT鏈

(c) IPVS比對數據包請求的服務是否為集群服務，若是，將請求報文中的源MAC地址修改為DIP的MAC地址，將目標MAC地址修改RIP的MAC地址，然後將數據包發至POSTROUTING鏈。 此時的源IP和目的IP均未修改，僅修改了源MAC地址為DIP的MAC地址，目標MAC地址為RIP的MAC地址

(d) 由於DS和RS在同一個網路中，所以是通過二層來傳輸。POSTROUTING鏈檢查目標MAC地址為RIP的MAC地址，那麼此時數據包將會發至Real Server。

(e) RS發現請求報文的MAC地址是自己的MAC地址，就接收此報文。處理完成之後，將響應報文通過lo介面傳送給eth0網卡然後向外發出。 此時的源IP地址為VIP，目標IP為CIP

(f) 響應報文最終送達至客戶端

1.5 在web端的操作有什麼含義？

1.5.1 RealServer為什麼要在lo介面上配置VIP？

既然要讓RS能夠處理目標地址為vip的IP包，首先必須要讓RS能接收到這個包。

在lo上配置vip能夠完成接收包並將結果返回client。

1.5.2 在eth0網卡上配置VIP可以嗎？

不可以，將VIP設置在eth0網卡上,會影響RS的arp請求,造成整體LVS集群arp緩存表紊亂，以至於整個負載均衡集群都不能正常工作。

1.5.3 為什麼要抑制ARP響應？

① arp協議說明

為了提高IP轉換MAC的效率，系統會將解析結果保存下來，這個結果叫做ARP緩存。

ARP緩存表是把雙刃劍

ARP廣播進行新的地址解析

測試命令

windows查看arp -a

③arp_announce和arp_ignore詳解

lvs在DR模式下需要關閉arp功能

arp_announce

對網路介面上，本地IP地址的發出的，ARP回應，作出相應級別的限制:

確定不同程度的限制,宣布對來自本地源IP地址發出Arp請求的介面

arp_ignore 定義

對目標地定義對目標地址為本地IP的ARP詢問不同的應答模式0

抑制RS端arp前的廣播情況

抑制RS端arp後廣播情況

1.6 LVS集群的工作模式

DR（Direct Routing）直接路由模式

NAT（Network Address Translation）

TUN（Tunneling）隧道模式

FULLNAT（Full Network Address Translation）

1.6.1 LVS集群的工作模式--NAT

通過網路地址轉換，調度器LB重寫請求報文的目標地址，根據預設的調度演算法，將請求分派給後端的真實伺服器，真實伺服器的響應報文處理之後，返回時必須要通過調度器，經過調度器時報文的源地址被重寫，再返回給客戶，完成整個負載調度過程。

收費站模式---來去都要經過LB負載均衡器。

NAT方式的實現原理和數據包的改變

(a). 當用戶請求到達Director Server，此時請求的數據報文會先到內核空間的PREROUTING鏈。 此時報文的源IP為CIP，目標IP為VIP

(b). PREROUTING檢查發現數據包的目標IP是本機，將數據包送至INPUT鏈

(c). IPVS比對數據包請求的服務是否為集群服務，若是，修改數據包的目標IP地址為後端伺服器IP，然後將數據包發至POSTROUTING鏈。 此時報文的源IP為CIP，目標IP為RIP

(d). POSTROUTING鏈通過選路，將數據包發送給Real Server

(e). Real Server比對發現目標為自己的IP，開始構建響應報文發回給Director Server。 此時報文的源IP為RIP，目標IP為CIP

(f). Director Server在響應客戶端前，此時會將源IP地址修改為自己的VIP地址，然後響應給客戶端。 此時報文的源IP為VIP，目標IP為CIP

LVS-NAT模型的特性

l RS應該使用私有地址，RS的網關必須指向DIP

l DIP和RIP必須在同一個網段內

l 請求和響應報文都需要經過Director Server，高負載場景中，Director Server易成為性能瓶頸

l 支持埠映射

l RS可以使用任意操作系統

l 缺陷：對Director Server壓力會比較大，請求和響應都需經過director server

1.6.2 LVS集群的工作模式--隧道模式TUN

採用NAT技術時，由於請求和響應的報文都必須經過調度器地址重寫，當客戶請求越來越多時，調度器的處理能力將成為瓶頸。

為了解決這個問題，調度器把請求的報文通過IP隧道(相當於ipip或ipsec )轉發至真實伺服器，而真實伺服器將響應處理後直接返回給客戶端用戶，這樣調度器就只處理請求的入站報文。

由於一般網路服務應答數據比請求報文大很多，採用 VS/TUN技術後，集群系統的最大吞吐量可以提高10倍。

VS/TUN工作流程,它的連接調度和管理與VS/NAT中的一樣，只是它的報文轉發方法不同。

調度器根據各個伺服器的負載情況，連接數多少，動態地選擇一台伺服器，將原請求的報文封裝在另一個IP報文中，再將封裝後的IP報文轉發給選出的真實伺服器。

真實伺服器收到報文後，先將收到的報文解封獲得原來目標地址為VIP地址的報文, 伺服器發現VIP地址被配置在本地的IP隧道設備上(此處要人為配置)，所以就處理這個請求，然後根據路由表將響應報文直接返回給客戶。

TUN原理和數據包的改變

(a) 當用戶請求到達Director Server，此時請求的數據報文會先到內核空間的PREROUTING鏈。 此時報文的源IP為CIP，目標IP為VIP 。

(b) PREROUTING檢查發現數據包的目標IP是本機，將數據包送至INPUT鏈

(c) IPVS比對數據包請求的服務是否為集群服務，若是，在請求報文的首部再次封裝一層IP報文，封裝源IP為為DIP，目標IP為RIP。然後發至POSTROUTING鏈。 此時源IP為DIP，目標IP為RIP

(d) POSTROUTING鏈根據最新封裝的IP報文，將數據包發至RS（因為在外層封裝多了一層IP首部，所以可以理解為此時通過隧道傳輸）。 此時源IP為DIP，目標IP為RIP

(e) RS接收到報文後發現是自己的IP地址，就將報文接收下來，拆除掉最外層的IP後，會發現裡面還有一層IP首部，而且目標是自己的lo介面VIP，那麼此時RS開始處理此請求，處理完成之後，通過lo介面送給eth0網卡，然後向外傳遞。 此時的源IP地址為VIP，目標IP為CIP

(f) 響應報文最終送達至客戶端

LVS-Tun模型特性

1.6.3 LVS集群的工作模式--FULLNAT

LVS的DR和NAT模式要求RS和LVS在同一個vlan中，導致部署成本過高；TUNNEL模式雖然可以跨vlan，但RealServer上需要部署ipip隧道模塊等，網路拓撲上需要連通外網，較復雜，不易運維。

為了解決上述問題，開發出FULLNAT

該模式和NAT模式的區別是：數據包進入時，除了做DNAT，還做SNAT（用戶ip->內網ip）

從而實現LVS-RealServer間可以跨vlan通訊，RealServer只需要連接到內網。類比地鐵站多個閘機。

1.7 IPVS調度器實現了如下八種負載調度演算法：

a) 輪詢（Round Robin）RR

調度器通過"輪叫"調度演算法將外部請求按順序輪流分配到集群中的真實伺服器上，它均等地對待每一台伺服器，而不管伺服器上實際的連接數和系統負載。

b) 加權輪叫（Weighted Round Robin）WRR

調度器通過"加權輪叫"調度演算法根據真實伺服器的不同處理能力來調度訪問請求。這樣可以保證處理能力強的伺服器處理更多的訪問流量。

調度器可以自動問詢真實伺服器的負載情況，並動態地調整其權值。

c) 最少鏈接（Least Connections） LC

調度器通過"最少連接"調度演算法動態地將網路請求調度到已建立的鏈接數最少的伺服器上。

如果集群系統的真實伺服器具有相近的系統性能，採用"最小連接"調度演算法可以較好地均衡負載。

d) 加權最少鏈接（Weighted Least Connections） Wlc

在集群系統中的伺服器性能差異較大的情況下，調度器採用"加權最少鏈接"調度演算法優化負載均衡性能，具有較高權值的伺服器將承受較大比例的活動連接負載。調度器可以自動問詢真實伺服器的負載情況，並動態地調整其權值。

e) 基於局部性的最少鏈接（Locality-Based Least Connections） Lblc

"基於局部性的最少鏈接" 調度演算法是針對目標IP地址的負載均衡，目前主要用於Cache集群系統。

該演算法根據請求的目標IP地址找出該目標IP地址最近使用的伺服器，若該伺服器 是可用的且沒有超載，將請求發送到該伺服器。

若伺服器不存在，或者該伺服器超載且有伺服器處於一半的工作負載，則用"最少鏈接"的原則選出一個可用的服務 器，將請求發送到該伺服器。

f) 帶復制的基於局部性最少鏈接（Locality-Based Least Connections with Replication）

"帶復制的基於局部性最少鏈接"調度演算法也是針對目標IP地址的負載均衡，目前主要用於Cache集群系統。

它與LBLC演算法的不同之處是它要維護從一個 目標IP地址到一組伺服器的映射，而LBLC演算法維護從一個目標IP地址到一台伺服器的映射。

該演算法根據請求的目標IP地址找出該目標IP地址對應的服務 器組，按"最小連接"原則從伺服器組中選出一台伺服器，若伺服器沒有超載，將請求發送到該伺服器。

若伺服器超載，則按"最小連接"原則從這個集群中選出一 台伺服器，將該伺服器加入到伺服器組中，將請求發送到該伺服器。

同時，當該伺服器組有一段時間沒有被修改，將最忙的伺服器從伺服器組中刪除，以降低復制的 程度。

g) 目標地址散列（Destination Hashing） Dh

"目標地址散列"調度演算法根據請求的目標IP地址，作為散列鍵（Hash Key）從靜態分配的散列表找出對應的伺服器，若該伺服器是可用的且未超載，將請求發送到該伺服器，否則返回空。

h) 源地址散列（Source Hashing）SH

"源地址散列"調度演算法根據請求的源IP地址，作為散列鍵（Hash Key）從靜態分配的散列表找出對應的伺服器。

若該伺服器是可用的且未超載，將請求發送到該伺服器，否則返回空。

1.8 LVS+Keepalived方案實現

1.8.1 keepalived功能

1. 添加VIP

2. 添加LVS配置

3. 高可用（VIP漂移）

4. web伺服器 健康 檢查

1.8.2 在負載器安裝Keepalived軟體

# 檢查軟體是否安裝

1.8.3 修改配置文件

lb03上keepalied配置文件

lb04的Keepalied配置文件

keepalived persistence_timeout參數意義 LVS Persistence 參數的作用

http://blog.csdn.net/nimasike/article/details/53911363

1.8.4 啟動keepalived服務

1.8.5 在web伺服器上進行配置

注意：web伺服器上的配置為臨時生效，可以將其寫入rc.local文件，注意文件的執行許可權。

使用curl命令進行測試

至此keepalived+lvs配置完畢

1.9 常見LVS負載均衡高可用解決方案

Ø 開發類似keepalived的腳本，早期的辦法，現在不推薦使用。

Ø heartbeat+lvs+ldirectord腳本配置方案，復雜不易控制，不推薦使用

Ø RedHat工具piranha，一個web界面配置LVS。

Ø LVS-DR+keepalived方案，推薦最優方案，簡單、易用、高效。

1.9.1 lvs排錯思路

3. 美團上顯示什麼是app版，什麼事web版，什麼是平台版是什麼意思

app是手機的軟體程序 web就是網頁版本電腦上保本…平台就是手機瀏覽器

4. 開發類似美團外賣的APP需要哪些功能

APP一此孫般情況下都是根據你所需要的功能去定製開發的，浙江天爾軟體技術有限公司在十幾年的開發經驗中總結出了開發一款APP應注意的事項，你可以參考下：

開發一個完整app需要掌握哪些知識

1、前期需求規劃與信息——你需要制定出一個完整的森改鏈需求文檔，功能文檔，流程圖，時序圖。

2、交互設計、UI設計——設計出基本且完善的原型圖和app基礎的交互設計效果，之後再根據這些設計出完整的UI界面並學會切圖，一些需要做自適應的素材圖片需要做點9patch。這里還需要你懂得px，pt和dp之間的換算，屏幕密度的換算和相互之間的系數，以便你的app能完美適應不同解析度設備。其中交互設計需要你懂得很多人機操作的技巧經驗，掌握Axure等交互工具的使用，UI設計需要你掌握Photoshop和Illustrator等操作。

3、使用ADT之類的開發環境進行app軟體開發，你最基本的也得掌握java語言，熟悉android環境和機制。

4、如果不是單機版的app，需要用到伺服器，那你還得掌握WebService相關知識和開發語

言，常用的有ASP.Net，PHP，JSP等。

5、熟悉並能開發資料庫。

6、某些功能需要做演算法，這還需要一定得專業知識，尤其是數學基礎。

7、熟悉API接殲早口開發，這里包括你自行開發API的能力以及調用第三方API的經驗。

8、熟悉TCP/IP，socket等網路協議和相關知識。

9、熟練掌握App發布的流程，真機調試技巧，證書，打包，上架。App開發其實不一定適合一個人搞，太費勁，除非是一個單機版的小應用，或者利用現成的app開發簡單的第三方應用，否則還是讓一個團隊來完成各自擅長的領域。

5. web伺服器是什麼

1、Web伺服器一般指網站伺服器，是指駐留於網際網路上某種類型計算機的程序，可以處理瀏覽器等Web客戶端的請求並返回相應響應，也可雀唯以放置網站文件，讓全世界瀏覽；可以放置數據文件，讓全世界下載。目前最主流的三個Web伺服器是Apache、Nginx、IIS。
2、WEB伺服器也稱為WWW(WORLDWIDEWEB)伺服器，主要功能是提供網上信息瀏覽服務。WWW是Internet的多媒體信息查詢工扮殲具，是Internet上近年才發展起來的頃缺培服務，也是發展最快和目前用的最廣泛的服務。正是因為有了WWW工具，才使得近年來Internet迅速發展，且用戶數量飛速增長。

6. 美團&餓了么web產品體驗報告

生活節奏的加快、學業壓力工作壓力的增大、都會進一步擠壓人們的用餐時間，外賣也就順理成章成為一個產業，或者說是餐飲行業的重要一環，學生一族、公司白領、宅男宅女和一些企業都是需要外賣的，所以用戶數量非常巨大，而且有連續橡喚宴重復購買率高的特性，因此外賣市場是個塊大的蛋糕。
美團：
擴張方向：公司白領、學生一族、宅男宅女
餓了么：
擴張方向：公司白領、學生一族、宅男宅女、高端商務/團購（依託大眾點評）
市場份額：
美團：
2014年底，美團外賣公布日訂單量已經突破150萬單，市場份額達到60%，學生高校的市場份額在70%左右
餓了么：
2014年，餓了么透露日訂單突破100萬單，峰值200萬單，市場份額佔到了60%。但同時也透露外賣的市場份額在降低。
且不論這些新聞數據到底有多少水分，想知道兩家的市場份額，我們來一次「曲線救國」，通過主流應用商城的APP下載量看看兩家市場份額

從下載量看，無論在哪個應用市場，美團外賣和餓了么都處在下載量的前兩位，而且與其它外賣APP相比優勢明顯
因此在外賣市場份額中，美團和餓鏈茄了么應該是旗鼓相當
從APP下載量推測市場份額雖然有失嚴謹梁銀（其中影響因素包括：運營推廣力度、APP體驗等等)。但從下載量也可以看出線下市場的大致情況
PS：其實早在一個月前就有關注這幾個外賣平台商的APP下載量，那個時候還是美團和餓了么互有勝負（如圖），一個月後竟然美團在這幾個主流應用市場的下載量全面超越了餓了么，說明：
從產品的角度來講美團APP的用戶體驗要更好
從線下來看，美團的擴張效率要比餓了么更高，應該得益於美團團購在線下的擴張經驗。
互聯網對外賣的改造：

交互設計

功能邏輯

服務內容

7. 像美團外賣這樣的APP用一種開發語言，能開發得出來嗎

像美團外賣這樣的APP用一種開發語言，能開發得出來嗎？答案是不能。

美團發展到現在可以說已經是一個【巨無霸】了，裡面集成了很多很多功能，除了核心的外賣，還有 旅遊 、 娛樂 、購物、出行，金融等等業務線，那麼這么多復雜的業務根本不可能用同一種開發語言實現。

那麼美團都用到哪些開發語言和技術了呢？下面就根據我的理解詳細說一下。

前端是把產品的核心服務交給用戶的呈現者，它的表述方式、展示形式以及交互邏輯都跟用戶息息相關，都影響著用戶使用產品的體驗，也就是說直接影響產品的用戶留存。

前端開發主要分為三大類型：Andriod、IOS和PC（H5） ,Android開發語言是Kotlin和Java，IOS開發語言是Object-c和Swift，PC（H5）開發語言就比較雜了，有JS、CSS、HTML，還有很多第三方的前端框架，比如Angular.js、vue.js、Bootstrap、JQuery等等。

關於後端的功能，這一點可以說是眾說紛紜，主要需要考慮的是如何實現功能、數據的交互流程和存取、平台的穩定性與性能等。

那麼後端都用到哪些開發語言和技術呢？

根據後端技術選型的標准，後端可選的開發語言和技術是非常多的。

比如Java體系的話，可以選用SpringMVC、Spring cloud、Hibernate，Mybatis、Mysql、Redis、Memcache、zookeeper、Kafka......；

比如python體系的話，可以選用Django、Flask、Tarnado、Web2py等，中間件都是通用的，Redis，MQ、MySQL、Kafka等都可以用在python體系中；

當然還有PHP、C、Perl等開發語言。

綜上所述，美團這個巨無霸公司，隨著業務線的擴展用到的技術肯定會越來越多，而且越來越復雜，技術快速變革的時代，適者生存的競爭性也會越來越激烈。

俗話說：羅馬不是一日建成的，任何事都不可能一蹴而就，包含技術。在以後的發展中美團也會逐步更新自己的技術和開發語言的。

至少三種語言。後端一種語言（比如Java丶Go丶Python丶PHP等），後端語言及生態比較成熟。下面重點聊前端App開發。

前台兩種語言（Android和iOS是不同的開發環境。比如Android用Java或者Kotlin，iOS採用Object C++或Swift），稱之為Native開發。

當然創業公司可以用一種前端語言寫App前端，這樣就不需要Android和蘋果分兩種語言寫，寫一次代碼可以編譯成Android和iOS的App，現在通行的方案有Vue之類的DOM渲染模式，以及ReactNative方案（RN）。性能上RN優於DOM渲染但低於用Native開發的App。所以美團這種公司，一定是Native方式寫App，但RN是初創項目不錯的選擇。

與RN競爭的還有一種新貴flutter，是google推出來的，但設計原理與RN不同，性能方面優於RN，只是目前生態不夠健全，國內有閑魚app是採用此技術。未來可能會佔一席之地。

最後，其實App開發已經是強努之末，我覺得主流應該是朝PWA和小程序方向發展。

你好，開發譬如美團這種APP，用一種語言是實現不了的，一個APP有安卓和蘋果兩個操作系統，開發能在安卓iOS端應用的APP主流的開發語言和技術是很多的，如後台有JAVA、C++、PHP、Python等多種開發語言，前端有kotlin、HTML、css、jquery、ajax、bootstrap、angular.js、react、vue.js、node.js、swift、object-c等多種語言和框架。

一個APP的開發是需要前端技術和後台技術共同配合完成，這樣的APP不論是功能還是性能都給用戶很好的體驗，單一開發語言畢竟技術支持有限，所以即使能開發出來，APP的用戶體驗也是不理想的。

一般APP有這幾種開發組合模式：1、原生安卓iOS開發，前端：JAVA、kotlin、swift、object-c後台：JAVA、PHP、C++等後台技術，這種模式開發周期長，成本高，性能好；2、混合APP開發即hybrid app，前端以網頁技術為主，穿插原生開發功能，兼具原生APP和web app的優點，如淘寶、微信等應用都是走的這個技術；3、web app，前端純網頁技術，後台為主流開發語言，這種模式開發速度快，成本低，界面體驗可能弱一些。

可見開發一款APP大多數都是多種語言配合完成，謝謝閱讀。

看完之前的評論，依然好奇為什麼一個語言不能完全勝任。

前端跨平台的方案有react native，cordova,flutter等，如果需要兼容開發小程序，h5頁面，可以採用taro來開發，一套代碼，所有平台通吃。

後端的方案有服務端運行時nodejs，大數據背景下運用而生的資料庫mobgodb，緩存解決方案redis，搜索工具elasticsearch，負載均衡ngix，基本上是需要什麼就有什麼

所以總結下來，一句話，一種語言可以實現類似美團這樣的app和小程序。為什麼美團使用的語言那麼多，一大原因估計是美團app開發的早，當時前端技術不成熟，工具沒現在這么多。

使用混合開發與C++ 進行跨平台開發，有好有壞。

C++ 進行跨平台開發

編寫一次，隨處運行。早在 2013 年，Dropbox 就採用上述策略進行移動開發，這背後的想法很簡單：用 C++ 編寫一次代碼，而不是用 Java 和 Objective-C 編寫兩次。那時，整個移動工程團隊相對還比較小，但需要支持快速增長的移動路線圖。因此，公司希望找到一種方法，使這個小團隊可以快速交付大量 Android 和 iOS 代碼。

如今，Dropbox 完全放棄了這個策略，轉而使用各個平台的原生語言（主要是 Swift 和 Kotlin ，這兩種語言在剛開始制定移動策略時還不存在）。

Hybrid App混合開發

Hybrid App主要以JS+Native兩者相互調用為主，從開發層面實現「一次開發，多處運行」的機制，成為真正適合跨平台的開發。Hybrid App兼具了Native App良好用戶體驗的優勢，也兼具了Web App使用HTML5跨平台開發低成本的優勢。

目前已經有眾多Hybrid App開發成功應用，比如美團、愛奇藝、支付寶等知名移動應用，都是採用Hybrid App開發模式。

移動應用開發的方式，目前主要有三種：

幾種模似都可以開發出應用，小應用無所謂，但是大流量應用，對圖形要求高的如 游戲 等原生開發的效果還是最好

支付寶打開很慢，就是因為採用混合開發，使用人多了不如原生開發

不行的哦。任何你看到的應用和網頁，都需要多個語言開發的，大的分比如前端和後端，用的語言都是不一樣的

8. web伺服器端的軟體可以採用iis

web伺服器端的軟體可以採用iis。根指岩頃據查詢相關資料信息，架設WEB伺服器使用的軟體有IIS、PWS和Apache等，它們各有特色，適合架設不同規模的網唯陸站，而架棗喚設在IIS是應用最方便和最廣泛的。

9. 幾種常用的Web伺服器

1. Tomcat
Tomcat是一個開放源代碼、運行servlet和JSP Web應用軟體的基於Java的Web應用軟體容器。Tomcat Server是根據servlet和JSP規范進行執行的，因此我們就可以說Tomcat Server也實行了Apache-Jakarta規范且比絕大多數商業應用軟體伺服器要好。
Tomcat是Java Servlet2.2和JavaServerPages 1.1技術的標准實現，是基於Apache許可證下開發的自由軟體。Tomcat是完全重寫的Servlet API 2.2和JSP 1.1兼容的Servlet/JSP容器。Tomcat使用了JServ的一些代碼，特別是Apache服務適配器。隨著Catalina Servlet引擎的出現，Tomcat第四版號的性能得到提升，使得它成為一個值得考慮的磨慶Servlet/JSP容器，因此目前許多WEB伺服器都是採用Tomcat。
2. JBOSS
JBoss是全世界開發者共同努力的成果，一個基於J2EE的開放源代碼的應用伺服器。 因為JBoss代碼遵循LGPL許可，你可以在任何商業應用中免費使用它，而不用支付費用。JBoss是一個管理EJB的容器和伺服器，支持EJB 1.1、EJB 2.0和EJB3.0的規范。但JBoss核心服務不包括支持servlet/JSP的WEB容器，一般與Tomcat或Jetty綁定使用。
3. IBM WebSphere
WebSphere軟體平台能夠幫助客戶在Web上創建自己的業務或將自己的業務擴展到Web上，為客戶提供了一個可靠、可擴展、跨平台的解決方案。作為IBM電子商務應用框架的一個關鍵組成部分，WebSphere軟體平台為客戶提供了一個使其能夠充分利用Internet的集成解決方案。
WebSphere軟體平台提供了一整套全面的集成電子商務軟體解決方案。作為一種基於行業標準的平台，它擁有足夠的靈活性，能夠適應市場的波動和商業目標的變化。它能夠創建、部署、管理、擴展出強大、可移植、與眾不同的電子商務應用，所有這些內容在必要時都可以與現有的傳統應用實現集成。以這一穩固的平台為基礎，客戶可以將不同的IT環境集成在一起，從而能夠最大程度地利用現有的投資。
WebSphere 針對以 Web 為中心的開發人員，他們都是在基本 HTTP伺服器和 CGI 編程技術上成長起來的。IBM 將提供 WebSphere 產品系列，通過提供綜合資源、可重復使用的組戚游山件、功能強大並易於使用的工具、以及支持 HTTP 和 IIOP 通信的可伸縮運行時環境，來幫助這些用戶從簡單的 Web 應用程序轉移到電子商務世界。
4. BEA WebLogic
BEA WebLogic Server 是一種多功能、基於標準的web應用伺服器，為企業構建自己的應用提供了堅實的基礎。各種應用開發、部署高中所有關鍵性的任務，無論是集成各種系統和資料庫，還是提交服務、跨 Internet 協作，起始點都是 BEA WebLogic Server。由於 它具有全面的功能、對開放標準的遵從性、多層架構、支持基於組件的開發，基於Internet 的企業都選擇它來開發、部署最佳的應用。
BEA WebLogic Server 在使應用伺服器成為企業應用架構的基礎方面繼續處於領先地位。BEAWebLogic Server 為構建集成化的企業級應用提供了穩固的基礎，它們以 Internet 的容量和速度，在連網的企業之間共享信息、提交服務，實現協作自動化。BEA WebLogic Server 的遵從 J2EE 、面向服務的架構，以及豐富的工具集支持，便於實現業務邏輯、數據和表達的分離，提供開發和部署各種業務驅動應用所必需的底層核心功能。
5. Apache
Apache源於NCSAhttpd伺服器，經過多次修改，成為世界上最流行的Web伺服器軟體之一。Apache是自由軟體，所以不斷有人來為它開發新的功能、新的特性、修改原來的缺陷。Apache的特點是簡單、速度快、性能穩定，並可做代理伺服器來使用。本來它只用於小型或試驗Internet網路，後來逐步擴充到各種Unix系統中，尤其對Linux的支持相當完美。
Apache是以進程為基礎的結構，進程要比線程消耗更多的系統開支，不太適合於多處理器環境，因此，在一個Apache Web站點擴容時，通常是增加伺服器或擴充群集節點而不是增加處理器。到目前為止Apache仍然是世界上用的最多的Web伺服器，世界上很多著名的網站都是Apache的產物，它的成功之處主要在於它的源代碼開放、有一支開放的開發隊伍、支持跨平台的應用（可以運行在幾乎所有的Unix、Windows、Linux系統平台上）以及它的可移植性等方面。

6. IIS
Microsoft的Web伺服器產品為InternetInformation Server (IIS)， IIS 是允許在公共Intranet或Internet上發布信息的Web伺服器。IIS是目前最流行的Web伺服器產品之一，很多著名的網站都是建立在IIS的平台上。IIS提供了一個圖形界面的管理工具，稱為 Internet服務管理器，可用於監視配置和控制Internet服務。
IIS是一種Web服務組件，其中包括Web伺服器、FTP伺服器、NNTP伺服器和SMTP伺服器，分別用於網頁瀏覽、文件傳輸、新聞服務和郵件發送等方面，它使得在網路(包括互聯網和區域網)上發布信息成了一件很容易的事。它提供ISAPI(IntranetServer API)作為擴展Web伺服器功能的編程介面；同時它還提供一個Internet資料庫連接器，可以實現對資料庫的查詢和更新。
（ASP、.net開發的程序一般只能在IIS上運行。）
以上伺服器：Tomcat、jboss、 Apache屬於開源的軟體，同時可以免費使用，IIS是由微軟Windows操作系統捆綁的軟體，雖然代碼沒有開源，也屬於免費的。Weblogic(BEA公司)和WebSphere（IBM）是屬於商業大型應用的軟體，如果客戶需求上需要、且預算充分的話可以考慮的。