台湾手机主板是哪种?是MTK吗?

Posted 2023-05-06

　　目前国内大部份手机都是台湾联发科的MTK芯片固化的MTK通用操作系统，该系统好处是成本低，产品研发速度块，用很低的成本单芯片实现很多功能，超长待机p3p4手写大屏幕大喇叭GPS收音机蓝牙双卡双待等等功能都可以轻松实现，非常适合中国国情，让广大劳动群众得到了物美价廉的手机产品，但是功能有是有但都不怎么强大！不过最近MTK新推出了6239多媒体芯片,该系统强化了拍照、拍摄、音乐、运行速度等功能。并支持500万像素的拍照功能，达到了30帧的视频播放.
　　MTK是现在市场上所有国内手机设计、制造商使用的最多的一个完整的手机产品解决方案，包括大部份的所谓台版机都是采用MTK的方案，大部分做手机的技术人员都对此有接触和了解。不过，MTK的整套软件系统十分庞大且复杂，很多刚接触这套系统的软件工程师一时不知如何进行配置和客户化定制。本文在此对整个MTK软件系统的工程结构和配置进行了简单介绍，希望通过此文和大家相互交流MTK软件系统的维护和修改、定制方面的心得。

　　MTK使用了nucleus实时操作系统，在其上做了个内核抽象层的封装，以适应多种实时操作系统，如oscar、ThreadX、nucleus。整个软件系统包括nucleus操作系统、平台设备驱动、协议栈、文件系统、WGUI、MMI、J2ME等。在这里MMI部分几乎包括了操作系统内核、协议栈、文件系统之上的所有部分，其中WGUI也在其中。

　　MTK的PC模拟版使用VC的编译器和链接器生成，ARM版使用ADS1.2的编译器和链接器生成。因为MTK的整个软件系统是一个很庞大而且复杂的工程，并且要支持多个MTK的产品系列和多家客户的客户化支持，使用集成开发环境(IDE)已经无法胜任，而且很难做到整个工程的自动构建和资源、代码的生成。所以MTK的软件系统使用了windows下的GNU开发工具链(MinGW)来进行工程的管理、配置和构建，MTK将MinGW放到了第三方工具中。另外还使用了perl脚本来解析用户输入的命令行参数，因此第三方工具中还包含了ActivePerl(windows下的perl解释器)。不过，整个软件系统并没有使用MinGW的全部工具，好象只使用了make这个工具，由几个Makefile控制了构建的过程，在编译和链接时根据最终生成PC模拟版还是ARM版而分别调用VC的编译器和链接器或ADS1.2的编译器和链接器。

　　接下来我们从具体的工程实践来看MTK的手机软件系统。

　　一. MTK手机软件系统的目录结构简介

　　MTK手机软件系统的主要目录如下所示，因整个工程的目录树非常庞大，为简单起见和减小篇幅，去除了在工程结构中相对不重要的目录。

　　.
　　|-- Fast_DL
　　|-- ROM
　　|-- adaptation
　　|-- applib
　　|-- bootloader
　　|-- config
　　|-- custom
　　| |-- app
　　| | `-- TOP_6227_BB
　　| |-- common
　　| |-- drv
　　| | |-- LCD
　　| | | `-- TOP_6227_LCM
　　| | `-- image_sensor
　　| | `-- MT9D011
　　|-- drv
　　|-- fs
　　|-- inc
　　|-- init
　　|-- interface
　　|-- j2me
　　|-- kal
　　|-- make
　　| |-- applib
　　| | |-- applib.def
　　| | |-- applib.inc
　　| | |-- applib.lis
　　| | `-- applib.pth
　　| |-- bootloader
　　| |-- config
　　| |-- custom
　　|-- media
　　|-- mmi
　　|-- modis
　　|-- mtk_lib
　　| `-- MT6227
　　| `-- S01
　　| `-- gprs
　　| |-- abm.lib
　　| |-- adaptation.lib
　　| |-- applib_inet.lib
　　|-- nucleus
　　|-- nvram
　　|-- plutommi
　　|-- tools

　　Fast_DL是开发时下载二进制映像和资源等的相关文件的目录。ROM是固化在ROM(可能是Flash的只读区)中的相关代码和头文件的目录，在给客户的发布版中大都只有一些导出函数的头文件，其中似乎还有一个跳转表的东西ROMSA_FuncTable。

　　kal是上面所说的内核抽象层的相关文件的目录。nvram是存取NV中的内容的相关代码的目录。nucleus是nucleus实时操作系统的目录，在给客户的发布版中只有头文件。drv是驱动相关的代码的目录。fs是文件系统相关的目录，好像只支持fat格式的。tools是工程相关工具的目录，包括MinGW。interface是系统各层的接口的目录，还包含重要模块的接口，如bluetooth、WIFI。config是一些系统和任务(task)相关头文件的目录，感觉不像是配置相关的目录。inc是中断控制和寄存器地址相关头文件的目录。

　　modis是PC模拟版的相关目录，包括了虚拟的GSM网络、SIM卡等，以及模拟器需要的字符串、图片等资源，还有PC模拟版的库、VC的相关工程文件。

　　mmi是一个缺省的空的MMI应用的目录，其中只是创建了一个什么也不干的MMI任务(线程)，处理下层发送上来的消息。plutommi是pluto组织(也可能是原本的mmi应用的代号)所写的整套MMI应用所在的目录，而实际上也就是我们需要定制和修改的MMI应用。其中的mmi目录中是pluto原本写好的mmi应用，mtkapp中是mtk后来所写的mmi应用，而Customer中是图片、字符串等资源的定制目录，大部分只是修改了字符串和图片、声音等的项目只要修改这个目录下的资源即可。

　　mtk_lib中是已经编译链接好的ARM版的库。因整个工程过于庞大，若完整的全新构建一次需要很长的时间。为了减少构建的时间，将一些已经完全调试稳定且基本不再改动的库和MTK不开放源代码的库放到这个目录，这样每次构建时只需要将这些库和其他编译好的库链接起来就可以了。这些库一般是ARM版的，若有thumb版的，则再增加一个和ARM版相对的thumb版的库，一般叫第二个库，如media_sec.lib就是thumb版的多媒体库。

　　custom是所有客户化项目的驱动程序及系统和MMI应用定制相关的文件的目录。如你的手机主板的RAM、FLASH等存储器的尺寸和地址空间有改动，MMI应用的特性有不同，蓝牙、WAP的配置有变化，或是有项目相关的新应用，其相关文件都是放在这个目录中和特定项目对应的目录下，如项目CUST1_6227，则放在CUST1_6227_BB下。要注意的是custom也作为一个模块存在，这使得其可以通过make目录中的custom模块的四个文件进行客户化的一些定制。

　　applib、bootloader、init、media、j2me等是这个系统各个层次的相对独立的模块各自的目录，其实drv和fs等目录也可以看成是相对独立的模块，只不过其更重要些而在前面介绍。这些目录包含了这些模块的C文件和头文件。每个目录(模块)都在下面的make目录中有相对应的目录保存构建时的编译链接配置文件。

　　make是工程构建过程中最重要的一个目录了，工程构建用的Makefile和一些中间配置文件将放在这里，Makefile在讲解构建过程时再具体介绍。在每个模块对应的目录下，都有四个文件控制了编译链接时的过程和配置。分别是：

　　<module_name>.def文件中是该模块构建过程中用的条件定义。

　　<module_name>.inc文件中是该模块所有用到的头文件所在目录的路径，是相对整个工程根目录的路径。

　　<module_name>.lis文件中列出了该模块的所有C文件，其路径也是相对整个工程根目录的。

　　<module_name>.pth文件中是该模块的所有C文件所在目录的路径，是相对整个工程根目录的路径。

　　build目录中保存了构建过程中产生的目标文件和库文件，及其他一些中间文件。

　　二. MTK手机软件系统的构建过程

　　如前面一节所述，MTK手机软件系统的构建使用了GNU的make，使得整个工程的构建可以自动进行，且可以灵活控制。整个构建过程由Make.bat、make2.pl、MoDIS.dsw、Gsm2.mak、Option.mak、<customer>_<project>.mak等文件控制。构建PC模拟版是通过msdev和VC的工程文件MoDIS.dsw来完成的。Gsm2.mak是构建ARM版的核心Makefile文件，整个构建过程由其控制，其他是一些启动、选项配置、子过程的文件。其关系图如下所示。

　　在MTK手机软件系统的根目录下有一个批处理文件Make.bat，这个批处理文件启动了整个工程的构建过程。在windows的命令行下，在该系统的根目录下输入命令make和相应的参数即可开始工程的构建，该批处理文件的使用方法如下所示。
　　Usage:
　　make ["customer"|"mt62xx"] "project" "action" ["modules"]

　　Description:
　　customer = mtk (Default customer)
　　= firefly17_demo (FIREFLY17_DEMO project)
　　= [mt6217|mt6219|mt6226|mt6227|mt6228|mt6229] (EVB only)
　　= ...

　　project = l1s (Layer 1 stand-alone)
　　= gsm (GSM only)
　　= gprs (GPRS only)
　　= basic (Basic Framework)

　　action = new (codegen, resgen, clean, update) (default)
　　= update or u (scan, compile, link)
　　= remake or r (compile, link)
　　= clean or c (clean)
　　= resgen (resgen)
　　= c,u (clean then update)
　　= c,r (clean then remake)
　　= codegen (codegen)
　　= viewlog (open edit to view build log)
　　= emigen (emigen)
　　= emiclean (emiclean)

　　module(s) = modules' name (kal, l1, ...)
　　=> OPTIONAL when action is one of (clean c remake r update u c,r c,u)

　　Example:
　　make gsm new (MT6205B EVB new)
　　make gprs codegen (MT6218B EVB codegen)
　　make mt6219 gprs update (MT6219 EVB update)
　　make firefly17_demo gprs new
　　make milan_demo gprs c,u init custom
　　make mt6219 gprs r init custom drv

　　其中较常用的action有new、update、remake、new_modis这几个。

　　new是全新开始构建整个工程的ARM版，包括图片、声音、字符串等资源都要重做，依赖的其他动作最多，是最彻底也是耗时最长的一个动作，一般得到一个新的MTK发布版本后要做一次。

　　update是重新更新整个工程的ARM版，该动作会扫描工程中文件和库的依赖关系，若依赖关系有变化会建立新的依赖关系，随后根据新的依赖关系重新编译链接有改动的部分，一般在增加或删除一些驱动或应用的情况下需要用update。

　　remake是重新编译整个工程的ARM版，该动作只是简单的重新编译链接有改动的部分，不检查依赖关系，是耗时最短的一个动作，也是最常用的动作。

　　new_modis是全新构建整个工程的PC模拟版，其调用VC的编译器和链接器得到一个可以在windows上运行的PC模拟版。MMI应用软件工程师可以在没有硬件板的情况下在PC上检查和调试自己写好的应用。

　　Make.bat实际上只起引导作用，其只有一行批处理语句perl make2.pl %*，于是运行该批处理文件后控制权转给了perl脚本make2.pl。在这个perl脚本中解析了用户输入的命令行参数，设置变量，准备make时需要的临时配置文件，随后根据生成的可运行映像是PC模拟版还是ARM版而分别调用不同的构建过程。

　　Pc模拟版的构建通过调用如下命令实现。

　　system("$msdev MoDIS.dsw /MAKE \"$argu - Win32 $modisDir\"

　　/OUT $MoDISLogDir\\$argu.log")

　　在这里$msdev就是VC的msdev，通过VC的工程文件MoDIS.dsw和后面的参数进行具体的构建过程。熟悉VC工程的朋友应该比较清楚，因此就不再具体解释了。之后将只以ARM版为主来讲解整个工程的构建过程。

　　ARM版的构建通过调用如下命令实现。

　　system("$makeCmd -f$makeFolder$myMF -r -R

　　CUSTOMER=$custom PROJECT=$project $action")

　　在这里$makeCmd是tools\make.exe，即GNU的make，$makeFolder$myMF是make\Gsm2.mak，$action是new、update、remake等。变量CUSTOMER和PROJECT分别是客户名和项目名，在构建过程中将根据此两个变量的值选定项目相关的配置文件，从而实现客户化的定制。通过给make指定ARM版的核心Makefile文件Gsm2.mak，开始了ARM版的构建过程。

　　Gsm2.mak文件中包含了Option.mak这个配置用的Makefile文件，另外还包含了一些以.tmp和.bld为后缀的由perl脚本 make2.pl生成的临时配置文件。这些临时配置文件主要是一些action如clean、remake等所需的变量设置，及客户化和版本号等的一些信息。Gsm2.mak控制了new、update、remake等动作的过程。具体分别如下所示。
　　new : cleanall cmmgen mmi_feature_check asngen codegen asnregen \
　　operator_check_lite update

　　update : cleanlog cleanbin mcddll_update codegen resgen cksysdrv remake

　　remake : cleanlog cleanbin genverno libs $(BIN_FILE) done

　　上面的构建过程的几个步骤中，最重要的两个步骤是libs、$(BIN_FILE) 。libs调用ARM版的编译器和连接器将各个模块目录下的C文件编译链接为独立的库。$(BIN_FILE)这个步骤将各个模块编译链接得到的库和 mtk_lib目录下的库一起链接起来得到一个映像文件，然后使用ADS的工具fromelf将映像文件生成以变量BIN_FILE命名的二进制文件，该文件可以下载到硬件板上运行。
　　libs这个步骤如下所示。
　　libs: cleanlib startbuildlibs $(COMPLIBLIST)

　　libs中真正进行编译链接的步骤是$(COMPLIBLIST)，要生成的库由变量COMPLIBLIST列出，在ARM版中，变量 COMPLIBLIST从变量COMPLIST得到。变量COMPLIST是在Option.mak及其包含的Makefile文件中赋值的。因有很多库需要编译链接，变量COMPLIBLIST展开后包含多个步骤，而这些步骤都是重复不变的，因此在定义步骤$(COMPLIBLIST)的构建过程时使用%.lib代替。%.lib这个步骤先清除了之前的一些依赖关系文件，将一些变量的设置写入~compbld.tmp这个临时文件中，然后给make指定Makefile文件comp.mak，完成库的编译和链接，如下所示。

　　%.lib:
　　…
　　@if /I %OS% EQU WINDOWS_NT \
　　(if /I $(BM_NEW) EQU TRUE \
　　(tools\make.exe -fmake\comp.mak -k -r -R $(strip $(CMD_ARGU)) COMPONENT=$* > $(strip $(COMPLOGDIR))\$*.log 2>&1)
　　\
　　else \
　　(tools\make.exe -fmake\comp.mak -r -R $(strip $(CMD_ARGU)) COMPONENT=$* > $(strip $(COMPLOGDIR))\$*.log 2>&1) \
　　) \
　　else \
　　(if /I $(BM_NEW) EQU TRUE \
　　(tools\make.exe -fmake\comp.mak -k -r -R $(strip $(CMD_ARGU)) COMPONENT=$* > $(strip $(COMPLOGDIR))\$*.log) \
　　else \
　　(tools\make.exe -fmake\comp.mak -r -R $(strip $(CMD_ARGU)) COMPONENT=$* > $(strip $(COMPLOGDIR))\$*.log) \
　　)

　　上面的命令语句中，参数-k是指有错误也要继续编译，-r和-R是指没有GNU make的默认规则和变量。COMPONENT=$*把当前要生成的库赋给变量COMPONENT。要注意%.lib匹配了所有要生成的库，但这个步骤一次只生成一个模块的库，这个步骤对所有匹配到的库都会执行一次。
　　comp.mak这个Makefile文件控制了模块的编译链接过程。在这个文件中，首先将当前模块要生成的库（由变量COMPONENT传入）设置给了变量TARGLIB。之后从<module_name>.lis文件中得到SRC_LIST和CPPSRC_LIST两个源文件列表，设定要编译的C文件、C++文件、汇编文件等的列表，和要链接的中间目标文件的列表。将<module_name>.inc、<module_name>.def、<module_name>.pth 文件中的头文件路径、C文件路径、编译链接参数等赋值给相应的变量。将平台相关（如6223、6225）的编译参数加上，确定使用ARM编译器还是 thumb编译器，是否支持ARM指令和thumb指令的interwork模式。最后进入库的编译链接过程。
　　库的编译链接由update_lib步骤完成，这个步骤直接依赖了$(TARGLIB)。目标$(TARGLIB)是由所有按照.c.obj、.s.obj、%.obj: %.cpp等规则编译得到的中间目标文件链接得到的。其主要过程如下所示。
　　$(TARGLIB):
　　...
　　@if exist $(FIXPATH)\$(CUS_MTK_LIB)\$(COMPONENT).lib \
　　(copy /z $(FIXPATH)\$(CUS_MTK_LIB)\$(COMPONENT).lib $(subst /,\,$(TARGLIB))) & \
　　($(LIB) -r $(TARGLIB) $(COMPOBJS_DIR)/*.obj) \
　　else \
　　($(LIB) -create $(TARGLIB) $(COMPOBJS_DIR)/*.obj)
　　...

　　Option.mak是整个工程构建过程中的总控配置文件，在这个文件中还包含了<customer>_<project>.mak和REL_CR_MMI_<project>.mak这两个项目相关的配置文件，用户自定义的配置文件USER_SPECIFIC.mak，另外还包含了一些临时生成的配置文件。这些配置文件在一起设置了工程构建过程中用到的编译器、链接器，库和二进制的工具，设置了编译链接时的参数，公共的头文件路径，设置了需要包含mtk_lib目录中的哪些既有的库，设置了需要生成的库等一系列相关的设置。这些设置都由一些重要的变量保存，具体在下一节中讲解。

　　三. MTK手机软件系统的配置

　　MTK手机软件系统的大部分配置都已经确定，基本上不需要再改变，一般是MTK发布新的版本时会作些改变，客户不大需要关心。最主要的配置文件是Option.mak，而客户化定制需要需要修改的主要是<costomer>_<project>.mak、REL_CR_MMI_<project>.mak这两个文件。

　　Option.mak文件中设置了工程构建时用到的编译器、链接器、库管理、二进制文件生成等工具的路径和可执行程序名，设置了基本的编译链接参数，指定CPU类型(ARM7EJ-S)，确定最终使用的库列表(COMPLIST)。

　　一个项目是由工程中的多个基本库、第三方库和由源代码新编译链接的库组成的，最终这些库链接到一起得到一个完整的可执行映像文件。由哪些新编译链接的库来组成一个项目是由四个关键的变量决定，其中一个是前面提到的COMPLIST，另外三个分别是CUS_REL_SRC_COMP、 CUS_REL_PAR_SRC_COMP、CUS_REL_MTK_COMP。这个几个变量的关系如下所示。

　　# *************************************************************************

　　# Custom Release Component Configuration

　　# *************************************************************************

　　# Be sure the following:

　　# 1. CUS_REL_SRC_COMP + CUS_REL_PAR_SRC_COMP =COMPLIST(CUSTOM_RELEASE = True)

　　# 2. CUS_REL_SRC_COMP + CUS_REL_PAR_SRC_COMP + CUS_REL_MTK_COMP = COMPLIST(CUSTOM_RELEASE = False)

　　COMPLIST确定了该项目最终是由哪些库（组件）组成的。MTK的内部版本构建时，则包括 CUS_REL_SRC_COMP、 CUS_REL_PAR_SRC_COMP、 CUS_REL_MTK_COMP这些库。客户版本构建时，则只包括 CUS_REL_SRC_COMP、 CUS_REL_PAR_SRC_COMP这些库。手机设计公司构建的版本都是客户版本，因此只要改变 CUS_REL_SRC_COMP、 CUS_REL_PAR_SRC_COMP这两个变量的值即可以定制自己的项目了。

　　MTK_LIBS确定了该项目最终包含了哪些MTK提供的基本库。

　　COMPOBJS确定了该项目最终包含了哪些第三方提供的不带源代码的库。变量CUS_RES_OBJ_LIST用于把这些第三方库随项目发布。

　　Option.mak和REL_CR_MMI_<project>.mak这两个文件都有对这两个变量CUS_REL_SRC_COMP、 CUS_REL_PAR_SRC_COMP赋值。但Option.mak文件只是设定了整个工程需要的基本库，如手写、图形解码等，和特定项目没有关系。因此客户要定制自己的项目只需要修改REL_CR_MMI_<project>.mak这个文件对这两个变量的赋值即可。

　　<costomer>_<project>.mak文件也有对COMPLIST的赋值，但这只是对MTK的内部版本有用，客户版本没有影响。值得注意的是，该项目的绝大部分功能特性(feature)是在这个文件中确定的，如使用的sensor、支持哪些音视频格式、电话本大小、LCD屏幕大小等。下面是该文件中的部分内容。

　　J2ME_SUPPORT = NONE # J2ME support: NONE, MTK_J2ME, J2ME_LIB, \
　　MTK_J2MEHI, J2MEHI_LIB, MTK_DUMMYVM

　　DRM_SUPPORT = NONE #DRM VENDOR: NONE, MTK, BSCI

　　DRM_VERSION = NONE # DRM VERSION: NONE, V01, V02, ALL

　　AMRWB_DECODE = TRUE # TRUE/FALSE

　　AMRWB_ENCODE = FALSE # TRUE/FALSE
　　# MT6219 DSP cannot support AMRWB_ENCODE when GPRS connection

　　JPG_DECODE = JPG_HW # NONE, JPG_HW, JPG_SW

　　JPG_ENCODE = JPG_HW # NONE, JPG_HW, JPG_SW

　　GIF_DECODE = TRUE # TRUE/FALSE

　　PNG_DECODE = NONE # NONE, PNG_HW, PNG_SW

　　DAF_DECODE = TRUE # TRUE/FALSE

　　MJPG_SUPPORT = FALSE # TRUE/FALSE

　　MP4_CODEC = TRUE # TRUE/FALSE

　　AAC_DECODE = TRUE # TRUE/FALSE

　　ISP_SUPPORT = TRUE # TRUE/FALSE

　　CMOS_SENSOR = OV7660 # OV9640, PAS105, PAS302, NONE, MT9D011, \
　　MT9M111, OV9650

　　四. 增加模块的配置实例

　　若我们需要加入zlib这么一个模块(zlib包含了很多程序都用到的压缩和解压函数)，我们可以按如下步骤进行。

　　1. 把zlib的源代码包拷贝到你的MTK软件系统根目录下，这样所有的zlib代码都在zlib目录或zlib-1.2.3目录下(用哪个目录名由你的喜好来确定)，在此为简单起见就放在zlib目录。

　　2. 在make目录下新增一个zlib的目录(最好和根目录下的目录名一样)，增加四个文件，分别是zlib.def、zlib.inc、zlib.lis、zlib.pth。zlib.def文件只要加上APCS_INTWORK就可以了，其他三个文件中加上源文件及其目录、头文件目录即可。

　　3. 在REL_CR_MMI_<project>.mak这个文件的合适位置加上如下语句。

　　CUS_REL_SRC_COMP += zlib

　　4. 把这个工程remake一下，若没有错误，zlib模块就成功加上去了。其他模块就可以调用zlib提供的压缩和解压缩函数了。

　　若我们需要加入一个没有源代码的第三方库，譬如加入wifi，我们可以按如下步骤进行。

　　1. 把wifi的所有第三方库文件拷贝到一个新建的wifi目录下。

　　2. 在Option.mak这个文件的合适位置加上如下语句。

　　ifeq ($(strip $(WIFI_SUPPORT)),WIFI_LIB)

　　COMPOBJS += wifi\sslplus.lib

　　CUS_REL_OBJ_LIST += wifi\sslplus.lib

　　COMPOBJS += wifi\sb.lib

　　CUS_REL_OBJ_LIST += wifi\sb.lib

　　endif 参考技术A 那看你说的哪个牌子了... 参考技术B 大多数是吧 还有国产的山寨机

Dubbo面试八连问，这些你都能答上来吗？

1. Dubbo是什么？

2. Dubbo能做什么？

3. Dubbo内置了哪几种服务容器？

4. Dubbo 核心的配置有哪些？

5. Dubbo有哪几种集群容错方案，默认是哪种？

6. Dubbo有哪几种负载均衡策略，默认是哪种？

7. Dubbo默认使用的是什么通信框架，还有别的选择吗？

8. 你觉得用Dubbo好还是SpringCloud好？

1.Dubbo是什么？

Dubbo是阿里巴巴开源的基于 Java 的高性能 RPC 分布式服务框架，现已成为 Apache 基金会孵化项目。致力于提供高性能和透明化的RPC远程服务调用方案，以及SOA服务治理方案。

简单的说，dubbo就是个服务框架，如果没有分布式的需求，其实是不需要用的，只有在分布式的时候，才有dubbo这样的分布式服务框架的需求，并且本质上是个服务调用的东东，说白了就是个远程服务调用的分布式框架（告别Web Service模式中的WSdl，以服务者与消费者的方式在dubbo上注册）

其核心部分包含:

1. 远程通讯: 提供对多种基于长连接的NIO框架抽象封装，包括多种线程模型，序列化，以及“请求-响应”模式的信息交换方式。

2. 集群容错: 提供基于接口方法的透明远程过程调用，包括多协议支持，以及软负载均衡，失败容错，地址路由，动态配置等集群支持。

3. 自动发现: 基于注册中心目录服务，使服务消费方能动态的查找服务提供方，使地址透明，使服务提供方可以平滑增加或减少机器。

2. Dubbo能做什么？

1. 透明化的远程方法调用，就像调用本地方法一样调用远程方法，只需简单配置，没有任何API侵入。

2. 软负载均衡及容错机制，可在内网替代F5等硬件负载均衡器，降低成本，减少单点。

3. 服务自动注册与发现，不再需要写死服务提供方地址，注册中心基于接口名查询服务提供者的IP地址，并且能够平滑添加或删除服务提供者。

Dubbo采用全Spring配置方式，透明化接入应用，对应用没有任何API侵入，只需用Spring加载Dubbo的配置即可，Dubbo基于Spring的Schema扩展进行加载。

3.Dubbo内置了哪几种服务容器？

Spring Container

Jetty Container

Log4j Container

4.Dubbo 核心的配置有哪些？

配置关系：

5.Dubbo有哪几种集群容错方案，默认是哪种？

6.Dubbo有哪几种负载均衡策略，默认是哪种？

7.Dubbo默认使用的是什么通信框架，还有别的选择吗？

Dubbo 默认使用 Netty 框架，也是推荐的选择，另外内容还集成有Mina、Grizzly。

8.你觉得用Dubbo好还是SpringCloud好？

没有好坏，只有适合不适合。

 

dubbo的优势

 

• 单一应用架构，当网站流量很小时，只需一个应用，将所有功能都部署在一起，以减少部署节点和成本。此时，用于简化增删改查工作量的 数据访问框架（ORM）是关键。

• 垂直应用架构，当访问量逐渐增大，单一应用增加机器带来的加速度越来越小，将应用拆成互不相干的几个应用，以提升效率。此时，用于加速前端页面开发的 Web框架（MVC）是关键。

• 分布式服务架构，当垂直应用越来越多，应用之间交互不可避免，将核心业务抽取出来，作为独立的服务，逐渐形成稳定的服务中心，使前端应用能更快速的响应多变的市场需求。此时，用于提高业务复用及整合的 分布式服务框架（RPC）是关键。

• 流动计算架构当服务越来越多，容量的评估，小服务资源的浪费等问题逐渐显现，此时需增加一个调度中心基于访问压力实时管理集群容量，提高集群利用率。此时，用于提高机器利用率的 资源调度和治理中心（SOA）是关键。

 

SpringCloud优势

 

• 约定优于配置

• 开箱即用、快速启动

• 适用于各种环境

• 轻量级的组件

• 组件支持丰富，功能齐全

 

两者相比较

1、dubbo由于是二进制的传输，占用带宽会更少

2、springCloud是http协议传输，带宽会比较多，同时使用http协议一般会使用JSON报文，消耗会更大

3、dubbo的开发难度较大，原因是dubbo的jar包依赖问题很多大型工程无法解决

4、springcloud的接口协议约定比较自由且松散，需要有强有力的行政措施来限制接口无序升级

5、dubbo的注册中心可以选择zk,redis等多种，springcloud的注册中心只能用eureka或者自研

根据具体的团队水平，业务情况等特点，dubbo和SpringCloud各自可以发挥各自不同的优势，没有最好的框架，只有最合适的。（这道题比较灵活，要是提前知道对方公司采用的是哪个，可以使劲吹哪个~）

 

最近三期

【23期】请你谈谈关于IO同步、异步、阻塞、非阻塞的区别

【24期】请你谈谈单例模式的优缺点,注意事项,使用场景

【25期】这三道常见的面试题，你有被问过吗？