40-互联网架构模板：“开发层”和“服务层”技术

开发层技术

开发框架

指定一个大的技术方向，然后使用统一的框架。

对于框架的选择，有一个总体原则：优先选择成熟的框架，避免盲目追逐新技术。

成熟的框架资料文档齐备，各种坑基本上都有人踩过了，遇到问题很容易通过搜索来解决。
成熟的框架受众更广，更容易招到合适的人才。
成熟的框架更稳定，不会出现大的变动，适合长期发展。

Web 服务器

开发框架只负责完成业务功能的开发，真正运行起来给用户提供服务，还需要服务器的配合。

互联网行业一般都是挑选一个流行的开源服务器即可。大一点的公司，可能会在开源服务器的基础上，结合自己的业务进行二次开发，一般的公司只需要将开源的服务器摸透，优化一下参数，调整一下配置就差不多可以了。

选择服务器跟开发语言有关。例如：JAVA的tomcat，jboss等。当然最保险的是apache，它什么语言都支持。

不需要担心apache的性能问题，等业务发展到apache撑不住的时候再考虑切换也不迟，那时候有钱、有人、有时间。

容器

以Docker为代表的容器在BAT级别的公司已经有很多的应用了。

传统的虚拟化技术是虚拟机，解决了跨平台的问题，但由于虚拟机太庞大、启动太慢，运行时占用太多的资源，在互联网公司并没有大规模的应用。而Docker的容器技术，虽然没有跨平台，但是启动快，几乎不占用资源，推出后立刻就火了起来。预计是技术发展的主流方向。

Docker不仅仅是虚拟化或者容器技术、它将很大的改变目前的技术趋势：

运维方式会发生革命性的变化：Docker启动快，几乎不占用资源，随时启动和停止，基于Docker打造自动化运维、智能化运维将会成为主流方式。
设计模式会发生本质的改变：启动一个新的容器实例代价如此之低、将鼓励设计思想朝“微服务”的方式发展。

例如：一个传统的网站包括登录、注册、页面访问、搜索等功能，在没有容器的情况下，除非有特别大的访问量，否则这些功能一开始都是集成在一个系统里面的。有了容器技术后，一开始就可以将这些功能按照服务的方式设计，避免后续访问量增大地又要重构系统。

服务层技术

服务层的主要目标就是为了降低系统间互相关联的复杂度。因为随着业务的发展，业务系统会越来越多，例如开发A系统的业务，需要B、C、D等十几个系统进行合并。从数据的角度来看，复杂度呈指数级上升。

配置中心

配置中心就是集中管理各个系统的配置。

当系统数量不多时，一般都是各系统自己管理自己的配置，但系统数量多了以后，这样处理会出现问题：

某个功能上线时，需要多个系统配合上线，分散配置时，操作效率低，配置检查、沟通协调需要耗费较多时间。
处理线上问题时，需要多个系统配合检查时，分散配置时，操作效率低，配置检查、沟通协调需要耗费较多时间。
各系统自己配置时，一般是通过文本编译器的方式修改的，没有自动的校验机制，容易配置错误，而且很难发现。

例如:把IP地址的中的0配置成大写的O,肉眼很难看出，但是通过程序检查就很容易。

实现配置中心就是为了解决上面的这些问题，将配置中心做成通用系统的好处在于：

集中配置多个系统，效率高。
所有配置都在一个集中的地方，检查方便，协作效率高。
配置中心可以实现程序化的规则检查，避免常见的错误。
配置中心相当于备份了系统的配置，当某些情况下需要搭建新的环境时，能够快速搭建环境和恢复业务。

通过“系统标识+host+port”来标识唯一一个系统运行实例中常见的设计方法。

Alt 配置中心

服务中心

系统数量不是很多时，系统间的调用一般都是直接通过配置文件记录在各系统内部的，但当系统数量多了以后，这种方式就会有问题。

如有10个系统依赖A系统的X接口，A系统实现了一个新的接口Y，可以更好的实现X接口提供的功能，如果让已有10个系统都切换到Y接口，则这10个系统的几十上百台机器的配置都要修改，然后重启，效率很低。
如果A系统总共有20台机器，现在其中有5台出故障了，其它系统通过域名访问A系统，则域名缓存失效前，还是可能访问到这5台机器的。如果其它系统通过IP访问A系统，那么A系统每次增加或删除机器，其它所有10个系统的几百台机器都需要同步修改，这样的协调工作太大。

服务中心就是为了解决上面提到的跨系统依赖的“配置”和“调度”问题。

服务中心的实现一般有二种方式：服务名称系统和服务总线系统

服务名称系统

服务名称系统与DNS相似，DNS的作用是解析域名，服务名称系统是为了将Service名称解析为“host+port+接口名称”，但是和DNS一样，真正发起请求的还是请求方。
服务总线系统

相比服务名称系统，服务总线系统更进一步，由总线系统完成调用，服务请求方都不需要直接和服务提供方交互了。