互联网应用的架构不是一蹴而就的, 各种技术方案是在网站的不断发展中演进出来的
如果我们只看着高大上的技术方案去学习, 最终会学会了也不知道这些方案是为了解决什么问题!
知道架构发展的进程非常重要, 甚至比具体的架构方案还要重要, 这样我们就能以发展的眼光去根据需要自己设计架构

1. 方案1: 配置私藏

1.1 架构图

点击查看【processon】

1.2 方案解析

  • 以上图为例
  • user-service 服务做了服务高可用负载均衡, 所以有三个服务器, 三个服务器IP各是 ip1 ip2 ip3
  • 每个 业务service 作为调用链上游, 各自配置了一个 user-service.conf 文件, 其中记录了 user-serivce 的各个服务器的IP
  • 正常情况下各个 业务service 能够很好的调用 user-service 提供的服务

1.3 问题

  • 当 user-service 发生改动, 例如 扩容 缩容 宕机 迁移 等情况的时候, 各个 业务service 对此完全无感知
  • 各业务service想要获取 user-service 最新的状态, 必须由人工给每个 业务service 手动修改他们的 user-service.conf
  • user-service 想要知道有多少个调用方也很难, 无法进行有效的管理
  • 通知各个调用方进行配置修改, 很可能需要几周的时间才能完成

2. 方案2: 全局配置文件

  • 架构的升级并不是一步到位的
  • 企业在升级架构的时候, 往往会用最低的成本去解决眼前的问题, 而不是去追求技术的高大上, 因为业务才是一个公司的核心
  • 运维层面需要制定规范, 建立 全局配置文件 , 对于通用的服务必须配置在 全局配置文件 中
  • 调用方如果想要调用通用服务, 必须引用 全局配置文件

2.1 架构图

点击查看【processon】

2.2 方案解析

2.2.1

  • 业务服务引入 FileMonitor 组件和 DynamicConnectionPool 组件
  • FileMonitor 组件是用来监听文件改动的组件
  • DynamicConnectionPool 组件是用来动态管理服务连接池的组件
  • user-service服务器发生变动, 则手动修改 global.conf 文件中的配置
  • 当 FileMonitor 监听到 global.conf 文件发生变化会通知 DynamicConnectionPool 修改user-service服务的连接池

2.2.2

  • 如果没有FileMonitor 组件和 DynamicConnectionPool 组件也是可以的
  • 只不过需要各业务service多一次重启操作来更新对user-service的配置
  • 在业务快速迭代的初期, 其实重启操作根本不是事
  • 根据需要去选择方案

2.3 问题

  • 虽然此方案不需要每个人修改配置, 但是依然不是完全自动化, 还是需要有人修改配置
  • 而且服务方也不知道有哪些调用方调用自己
  • 当服务数量太大的情况下, 将又会变得无法管理

3. 方案3: 配置中心

  • 只有加特技才能解决自动化的问题

    3.1 架构图

    点击查看【processon】

    3.2 方案解析

  • 每个服务都是平等的

  • 每个服务都会将自己的元信息注册到配置中心
  • 每个服务的元信息发生变化, 都会通知依赖方, 依赖方会根据自己的需要调整配置和连接池
  • 服务发现, 服务治理, 动态配置等功能都是基于配置中心搞出来的
  • 至于配置中心的高并发高可用问题, 我们这里暂时不讨论

3.3 总结

  • 只有当服务大道一定程度的时候才值得使用配置中心, 比如服务有上百个了
  • 维护开发配置中心是需要花费大量的人力的
  • 所以企业应当一切以业务为先, 技术是为业务服务的, 没有高低之分