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

极客时间：《从 0 开始学架构》:互联网架构模板：“开发层”和“服务层”技术

开发层技术

1、开发框架

互联网公司都会指定一个大的技术方向，然后使用统一的开发框架。使用统一的开发框架能够有效解决：

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

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

2、Web服务器

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

3、容器

千万不要以为 Docker 只是一个虚拟化或者容器技术，它将在很大程度上改变目前的技术形势：

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

服务层技术

互联网业务的不断发展带来了复杂度的不断提升，业务系统也越来越多，系统间相互依赖程度加深。
服务层的主要目标其实就是为了降低系统间相互关联的复杂度。

• 1. 配置中心
     配置中心就是集中管理各个系统的配置。
     下面是配置中心简单的设计，其中通过“系统标识 + host + port”来标识唯一一个系统运行实例是常见的设计方法。
     
• 2. 服务中心
     当系统数量不多的时候，系统间的调用一般都是直接通过配置文件记录在各系统内部的，但当系统数量多了以后，这种方式就存在问题了。
     服务中心就是为了解决跨系统依赖的“配置”和“调度”问题
     服务中心的实现一般来说有两种方式：服务名字系统和服务总线系统。

• 服务名字系统(Service Name System)
  服务名字系统是为了将 Service 名称解析为“host + port + 接口名称”
  基本的设计如下：
  

• 服务总线系统(Service Bus System)
  服务总线系统：由总线系统完成调用，服务请求方都不需要直接和服务提供方交互了。
  基本的设计如下：
  

服务名字系统”和“服务总线系统”简单对比如下表所示：

• 消息队列
  互联网业务的一个特点是“快”，这就要求很多业务处理采用异步的方式。
  传统的异步通知方式是由消息生产者直接调用消息消费者提供的接口进行通知的，但当业务变得庞大，子系统数量增多时，这样做会导致系统间交互非常复杂和难以管理，因为系统间互相依赖和调用，整个系统的结构就像一张蜘蛛网，如下图所示：
  

消息队列就是为了实现这种跨系统异步通知的中间件系统。消息队列既可以“一对一”通知，也可以“一对多”广播。
以微博为例：

对比前面的蜘蛛网架构，可以清晰地看出引入消息队列系统后的效果：

• 整体结构从网状结构变为线性结构，结构清晰；
• 消息生产和消息消费解耦，实现简单；
• 增加新的消息消费者，消息生产者完全不需要任何改动，扩展方便；
• 消息队列系统可以做高可用、高性能，避免各业务子系统各自独立做一套，减轻工作量；
• 业务子系统只需要聚焦业务即可，实现简单