互联网开发层和服务层技术了解

开发层技术

开发框架

互联网业务发展的一个特点：复杂度越来越高。复杂度增加的典型现象就是系统越来越多，不同的系统由不同的小组开发。如果每个小组用不同的开发框架和技术，则会带来很多问题，典型的问题有：

• 技术人员之间没有共同的技术语言，交流合作少；
• 每类技术都需要投入大量的人力和资源并熟练精通；
• 不同团队之间人员无法快速流动，人力资源不能高效的利用

所以，互联网公司都会指定一个大的技术方向，然后使用统一的开发框架。例如，Java 相关的开发框架 SSH、SpringMVC、Play，Ruby 的 Ruby on Rails，PHP 的 ThinkPHP，Python 的 Django 等。

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

WEB服务器

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

独立开发一个成熟的 Web 服务器，成本非常高，况且业界又有那么多成熟的开源 Web 服务器，所以互联网行业基本上都是拿来主义，挑选一个流行的开源服务器即可，或则基于开源二次开发。

选择一个服务器主要和开发语言相关，例如，Java 的有 Tomcat、JBoss、Resin 等，PHP/Python 的用 Nginx，当然最保险的就是用 Apache 了，什么语言都支持。

容器

传统的虚拟化技术是虚拟机，解决了跨平台的问题，但由于虚拟机太庞大，启动又慢，运行时太占资源，在互联网行业并没有大规模应用；而以 Docker为代表 的容器技术，虽然没有跨平台，但启动快，几乎不占资源，推出后立刻就火起来了，进一步促进了微服务的发展。

服务层技术

服务层的主要目标其实就是为了降低系统间相互关联的复杂度

配置中心

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

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

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

• 集中配置多个系统，操作效率高；
• 所有配置都在一个集中的地方，检查方便，协作效率高；
• 配置中心可以实现程序化的规则检查，避免常见的错误。比如说检查最小值、最大值、是否 IP 地址、是否 URL 地址，都可以用正则表达式完成；
• 配置中心相当于备份了系统的配置，当某些情况下需要搭建新的环境时，能够快速搭建环境和恢复业务

服务中心

当系统数量不多的时候，系统间的调用一般都是直接通过配置文件记录在各系统内部的，但当系统数量多了以后，这种方式就存在问题了。比如说总共有 10 个系统依赖 A 系统的 X 接口，A 系统实现了一个新接口 Y，能够更好地提供原有 X 接口的功能，如果要让已有的 10 个系统都切换到 Y 接口，则这 10 个系统的几十上百台机器的配置都要修改，然后重启，可想而知这个效率是很低的。

服务中心就是为解决跨系统依赖的配置和调度问题

服务中心的实现一般来说有两种方式：服务名字系统和服务总线系统。

服务名字系统

服务名字系统(Service Name System)与 DNS(Domain Name System)的性质基本类似

DNS 的作用将域名解析为:：IP 地址，主要原因是我们记不住太多的数字 IP，域名就容易记住。
服务名字系统是为了将 Service 名称解析为：host + port + 接口名称。基本的设计如下：

服务总线系统

服务总线系统(Service Bus System)与计算机总线本质类似。相比服务名字系统，服务总线系统更进一步了：由总线系统完成调用，服务请求方都不需要直接和服务提供方交互了。基本的设计如下：

两者对比

消息队列

互联网业务的一个特点是快，这就要求很多业务处理采用异步的方式。例如，大 V 发布一条微博后，系统需要发消息给关注的用户，我们不可能等到所有消息都发送给关注用户后再告诉大 V 说微博发布成功了，只能先让大 V 发布微博，然后再发消息给关注用户。

消息队列就是为了实现这种跨系统异步通知的中间件系统。消息队列既可以一对一通知，也可以一对多广播。业界已经有很多成熟的开源实现方案如：RocketMQ、Kafka、ActiveMQ 等。

--------来源《极客课程》∙ 学习摘要