对付框架的选择，有一个总的原则：优选成熟的框架，避免盲目追逐新技能！
缘故原由有：
开拓框架只是卖力完成业务功能的开拓，真正能够运行起来给用户供应做事，还须要做事器合营。独立开拓一个成熟的Web做事器，本钱非常高，况且业界又有那么多成熟的开源Web做事器，以是互联网行业基本上都是“拿来主义”，挑选一个盛行的开源做事器即可。大一点的公司，可能会在开源做事器的根本上，结合自己的业务特点做二次开拓，例如淘宝的Tengine，但一样平常公司基本上只须要将开源做事器摸透，优化一下参数，调度一下配置就差不多了。
选择一个做事器紧张和开拓措辞干系，例如，Java的有Tomcat、JBoss、Resin等，PHP/Python的用Nginx，当然最保险的便是用Apache了，什么措辞都支持。你可能会担心Apache的性能之类的问题，实在不用过早担心这个，等到业务真的发展到Apache撑不住的时候再考虑切换也不迟，那时候你有的是钱，有的是人，有的是韶光。
容器是最近几年才开始火起来的，个中以Docker为代表，在BAT级别的公司已经有较多的运用。传统的虚拟化技能是虚拟机，办理了跨平台的问题，但由于虚拟机太弘大，启动又慢，运行时太占资源，在互联网行业并没有大规模运用；而Docker的容器技能，虽然没有跨平台，但启动快，险些不占资源，推出后急速就火起来了，估量Docker类的容器技能将是技能发展的主流方向。
千万不要以为Docker只是一个虚拟化或者容器技能，它将在很大程度上改变目前的技能形势：
运维办法会发生革命性的变革：Docker启动快，险些不占资源，随时启动和停滞，基于Docker打造自动化运维、智能化运维将成为主流办法。设计模式会发生实质上的变革：启动一个新的容器实例代价如此低，将鼓励设计思路朝“微做事”的方向发展。例如，一个传统的网站包括登录注册、页面访问、搜索等功能，没有用容器的情形下，除非有特殊大的访问量，否则这些功能开始时都是集成在一个别系里面的；有了容器技能后，一开始就可以将这些功能按照做事的办法设计，避免后续访问量增大时又要重构系统。
做事层技能互联网业务的不断发展带来了繁芜度的不断提升，业务系统也越来越多，系统间相互依赖程度加深。比如说为了完成A业务系统，可能须要B、C、D、E等十几个其他系统进行互助。从数学的角度进行评估，可以创造系统间的依赖是呈指数级增长的：3个别系相互关联的路径为3条，6个别系相互关联的路径为15条。做事层的紧张目标实在便是为了降落系统间相互关联的繁芜度。
配置中央配置中央便是集中管理各个别系的配置。当系统数量不多的时候，一样平常是各系统自己管理自己的配置，但系统数量多了往后，这样的处理办法会有问题：
某个功能上线时，须要多个别系合营一起上线，分散配置时，配置检讨、沟通折衷须要耗费较多韶光。处理线上问题时，须要多个别系合营查询干系信息，分散配置时，操作效率很低，沟通折衷也须要耗费较多韶光。各系统自己管理配置时，一样平常是通过文本编辑的办法修正的，没有自动的校验机制，随意马虎配置缺点，而且很难创造。例如，我曾经碰着将IP地址的数字0误敲成了键盘的字母O，肉眼非常难创造，但程序检讨实在就很随意马虎。
实现配置中央紧张便是为理解决上面这些问题，将配置中央做成通用的系统的好处有：
集中配置多个别系，操作效率高。所有配置都在一个集中的地方，检讨方便，协作效率高。配置中央可以实现程序化的规则检讨，避免常见的缺点。比如说检讨最小值、最大值、是否IP地址、是否URL地址，都可以用正则表达式完成。配置中央相称于备份了系统的配置，当某些情形下须要搭建新的环境时，能够快速搭建环境和规复业务。整机磁盘坏掉、机器主板坏掉……碰着这些不可规复的故障时，基本上只能重新搭建新的环境。程序包肯定是已经有的，加上配置中央的配置，能够很快搭建新的运行环境，规复业务。否则几十个配置文件重新一个个去Vim中修正，耗时很长，还很随意马虎出错。下面是配置中央大略的设计，个中通过“系统标识 + host + port”来标识唯一一个别系运行实例是常见的设计方法：
做事中央
当系统数量不多的时候，系统间的调用一样平常都是直接通过配置文件记录在各系统内部的，但当系统数量多了往后，这种办法就存在问题了。比如说统共有10个别系依赖A系统的X接口，A系统实现了一个新接口Y，能够更好地供应原有X接口的功能，如果要让已有的10个别系都切换到Y接口，则这10个别系的几十上百台机器的配置都要修正，然后重启，可想而知这个效率是很低的。
除此以外，如果A系统统共有20台机器，现在个中5台出故障了，其他系统如果是通过域名访问A系统，则域名缓存失落效前，还是可能访问到这5台故障机器的；如果其他系统通过IP访问A系统，那么A系统每次增加或者删除机器，其他所有10个别系的几十上百台机器都要同步修正，这样的折衷事情量也是非常大的。
做事中央便是为理解决上面提到的跨系统依赖的“配置”和“调度”问题。
做事中央的实现一样平常来说有两种办法：做事名字系统和做事总线系统。
做事名字系统（Service Name System）看到这个翻译，相信你会急速遐想到DNS，即Domain Name System。没错，两者的性子是基本类似的。DNS的浸染将域名解析为IP地址，紧张缘故原由是我们记不住太多的数字IP，域名就随意马虎记住。做事名字系统是为了将Service名称解析为“host + port + 接口名称”，但是和DNS一样，真正发起要求的还是要求方。基本的设计如下：做事总线系统（Service Bus System）看到这个翻译，相信你可能急速遐想到打算机的总线。没错，两者的实质也是基本类似的。比较做事名字系统，做事总线系统更进一步了：由总线系统完成调用，做事要求方都不须要直接和做事供应方交互了。基本的设计如下：“做事名字系统”和“做事总线系统”大略比拟如下表所示：
行列步队
互联网业务的一个特点是“快”，这就哀求很多业务处理采取异步的办法。例如，大V发布一条微博后，系统须要发给关注的用户，我们不可能等到所有都发送给关注用户后再见告大V说微博发布成功了，只能先让大V发布微博，然后再发给关注用户。
传统的异步关照办法是由生产者直接调用消费者供应的接口进行关照的，但当业务变得弘大，子系统数量增多时，这样做会导致系统间交各别常繁芜和难以管理，由于系统间相互依赖和调用，全体系统的构培养像一张蜘蛛网，如下图所示。
行列步队便是为了实现这种跨系统异步关照的中间件系统。行列步队既可以“一对一”关照，也可以“一对多”广播。以微博为例，可以清晰地看到异步关照的实现和浸染，如下图所示。
比拟前面的蜘蛛网架构，可以清晰地看出引入行列步队系统后的效果：
整体构造从网状构造变为线性构造，构造清晰。生产和消费解耦，实现大略。增加新的消费者，生产者完备不须要任何改动，扩展方便。行列步队系统可以做高可用、高性能，避免各业务子系统各自独立做一套，减轻事情量。业务子系统只须要聚焦业务即可，实现大略。行列步队系统基本功能的实现比较大略，但要做到高性能、高可用、时序性、事务性则比较难。业界已经有很多成熟的开源实现方案，如果哀求不高，基本上拿来用即可，例如，RocketMQ、Kafka、ActiveMQ等。但如果业务对的可靠性、时序、事务性哀求较高时，则要深入研究这些开源方案，否则很随意马虎踩坑。开源的用起来方便，但要改就很麻烦了。由于其相比拟较大略，很多公司也会花费人力和韶光重复造一个轮子，这样也有好处，由于可以根据自己的业务特点做快速的适配开拓。
