首先，本文所说的服务器技术，不包括Serverless，Serverless 能完成小的任务，但是难堪大用。 目前，常见的服务器段技术包括PHP框架，Spring Boot， 和 Node。Node的效率不如PHP和Srping Boot；而Sprint Boot流行程度更高，但是处理并发任务时，Spring Boot也是问题重重。PHP还有个WordPress+WooCommerce框架，非常适和商城项目，比SpringBoot开发速度快。 其实，还有一个服务器端技术，那就是 Nginx +Ｃ＋＋，而且，有现成的库可以使用（https://fastcgipp.isatec.ca/index.html）。该技术基于ＥＰＯＬＬ实现，我认为，该技术才是年轻一代的开发服务器技术的选项。 我有时候怀疑，当年微软为了延缓技术的进步，误导其他开发人员，所以，没有发布开源版的Ｃ＋＋服务器，而是搞出来一个ＩＩＳ（ａｓｐ），从而使得下一代程序员远离了服务器编程技术的核心。 个人看法，提个醒
微软不停推新版本的vs 实际上在强制推广 .net 下载Vs的码农越多，.net安装得就越多，然后在vs里集成c# 然后c++码农越感觉写c# 比写c++真香,闭着眼睛都能写代码
然后转移c#的码农越多，下载vs的c++码农越多,c++码农就越少，这就是微软的腾笼换鸟技术
谈不上PHP的粉，是一个快50岁的老程序员。感慨一下技术的变迁。感觉微软很努力的让程序员离开C++，服务器端用IIS让人不需要C++，而PC端，用C#来替换C++，多年前还搞过VB Script试图替换Ｊａｖａｓｃｒｉｐｔ。 我的本意是，客户端使用Ｎｏｄｅ，而服务器端就该使用Ｃ＋＋，不会的，就去学，以上才是大道，啥问题都能解决
我猜是某个库链接不对，以下是几个常见的库文件的写法 下面的CMake文件（系统为Ubuntu 20.04），链接了MySQL8, SSL, libjson等常见的库文件，您看看您想链接啥库吧。
cmake_minimum_required(VERSION 3.10)
project(larry VERSION 1.0)
set(CMAKE_CXX_STANDARD 14) set(CMAKE_CXX_STNADARD_REQUIRED True)
add_subdirectory(libspawnfcgi ) add_subdirectory(libfastcgipp) add_subdirectory(libcommon)
find_package(Threads REQUIRED) find_package(Boost 1.71.0 COMPONENTS log thread system REQUIRED)
find_library(SSL_LIB NAMES ssl) find_library(CRYPTO_LIB NAMES crypto) find_library(MYSQL_LIBS NAMES mysqlcppconn) find_library(JSONCPP_LIB jsoncpp PATHS /usr/lib)
set(CURL_LIBRARY “-lcurl”) find_package(CURL REQUIRED)
find_package(OpenSSL REQUIRED)
add_executable(booking_overall app/server.cpp app/URL2ID.cpp app/ErrReport.cpp app/DataBase_base.cpp app/DataBase.cpp app/BaseHandler.cpp app/UserAuthHandler.cpp app/OpenAPIHandler.cpp app/BookingAPIHandler.cpp app/RequestHandler.cpp app/cgi_order.cpp app/controllers/goodInfo/GoodInfo.cpp app/controllers/data/Data.cpp app/controllers/help/Help.cpp app/controllers/otcUserLogin/OtcUserLogin.cpp app/controllers/send/Send.cpp app/controllers/otcMatchOrder/OtcMatchOrder.cpp app/controllers/superadmin/SuperAdmin.cpp app/services/jimai_verification_code/service.cpp app/services/otc_user/service.cpp app/services/jimai_session/service.cpp app/services/otc_user_wallet/service.cpp app/services/pg_user_wallet/service.cpp app/services/sys_user/service.cpp app/services/pg_account_log/service.cpp app/services/otc_good_category/service.cpp app/services/otc_good_config/service.cpp app/services/otc_transaction_complete/service.cpp app/services/pg_asset_config/service.cpp app/services/otc_areas/service.cpp app/services/otc_currency_quotation/service.cpp app/services/otc_notice/service.cpp app/services/otc_asset_config/service.cpp app/services/otc_help_center/service.cpp app/services/timetable/service.cpp app/services/cron_account/service.cpp app/services/cron_balance/service.cpp app/services/otc_team_asset_config/service.cpp app/services/otc_asset_change_log/service.cpp app/services/otc_user_follow_good/service.cpp app/services/otc_quotation_one_day/service.cpp app/services/otc_user_order/service.cpp app/services/otc_user_deposit/service.cpp app/services/otc_user_apply_order/service.cpp app/services/otc_shift_to_asset/service.cpp app/services/otc_pay_bind_log/service.cpp app/services/otc_open_account_log/service.cpp app/services/otc_currency_match/service.cpp app/services/otc_all_config/service.cpp app/utils/base64.cpp /usr/local/lib/libjson-c.a )
target_include_directories(booking_overall PUBLIC ${PROJECT_BINARY_DIR}/include ${PROJECT_BINARY_DIR}/libcommon/log ${PROJECT_BINARY_DIR}/libcommon/mysql ${Boost_INCLUDE_DIRS} "/usr/include/mysql-cppconn-8" "/usr/include/mysql-cppconn-8/jdbc" "/usr/include/mysql-cppconn-8/jdbc/cppconn" )
target_link_libraries(booking_overall PUBLIC ${SSL_LIB} ${CRYPTO_LIB} ${MYSQL_LIBS} ${JSONCPP_LIB} common fastcgipp spawnfcgi Threads::Threads ${CURL_LIBRARIES} OpenSSL::SSL )
说句不太客气的话。。。。大清早亡了。。单体式服务时代已经落幕了。。。 fastCGI…20年前的技术了。。一出问题，OS都麻烦的东西。。。 我推荐一个这是cpp的web开源架构: https://github.com/qicosmos/cinatra nginx 可以看看openResty … 服务器没有万能的银弹, 只有在不同场合下适用的选择… 纯C的+Mysql ODBC的服务见过么? 某老同志的系统, 应用于pos设备, 运行的稳如泰山… 还有.Net + Oracle + cpp + perl + weblogic( J2EE ) + ESB…的组合拳 现代服务器技术,往往都是各种技术组合而成, 而不是单一体系…我还没说各种MQ , cache, 等等服务外围技术… 所谓技术,能最佳解决问题的才是技术核心!
@hengbenkeji 50岁的程序员，怎么写出20岁刚接触编程的年轻人才考虑的语言和工具之争，老实说显得格局和见识远低于平均年纪的程序员。 不要说50岁了，我遇到N个40岁以上站在技术角度都更多的是能力和业务的思考，我觉得你得反思。
