HSF（一）HSF框架介绍及由来

主要问题

• 为什么要使用远程通信？
• 为什么远程通信要使用RPC服务？
• RPC服务的主体框架是什么？
• 为什么互联网公司要自研RPC框架？
• HSF框架的主题结构

本地通信

整体业务系统集成在一个应用中，通过本地调用来进行访问
（例如同一project不同方法互相调用）
缺点：

• 多个团队技术架构及代码风格不同，难以相互结合
• 不同团队发布频度不同难以互相协调
• 一个module发生故障会影响整个project，稳定性难以保证

远程通信以及RPC架构

为了避免上述问题，可以考虑通过将服务分模块开发，做到业务解耦以及提高发布自由度以及系统稳定性，
典型远程通信：

• RPC
• Web Server
• RMI

RPC服务即通过网络从远程计算机程序上请求服务，基础模型为典型的C/S架构
具体实现方法：HTTP协议

RPC框架

普通的RPC服务（例如HTTP调用），虽然可以一定程度到做到工程间的解耦，但仍然具有很多问题：

• 在连接建立与断开时信息体开销巨大，包含的信息如协议等又用不到，所以需要通过优化连接方式，做到RPC的性能提升
• 如果服务数量较多，问题的重点从如何进行RPC服务调用变成如何进行RPC服务治理

为了避免如上问题，Server（即服务提供者Provider）在启动后会将服务ID、IP地址以及端口信息注册至Registry中，Client（即服务调用者Consumer）想要调用某服务时会通过该ID向Registry订阅服务，Registry推送返回IP列表，Client再通过IP地址进行服务调用

如图仅展示了一组Client以及Server的调用过程，对于商业级别的业务，会有数万的Provider和Consumer同时运作，此时就需要一个Configuration（配置中心），对整个RPC服务进行管理、运维和治理。
Configuration管理的规则：

• Server分组规则
• 服务调用路由规则
• 调用权重规则
• 白名单
• 日志级别规则
• 动态负载配置规则
  

HSF框架

HSF是RPC服务框架的一种具体实现方式，本身没有服务端集群，整体服务调用都是通过Consumer和Provider点对点进行
其中Registry（注册中心）是通过ConfigServer承担的，Configuration（配置中心）是通过Diamond承担

除此之外，还有其他结构：

• 元数据存储：元数据即HSF服务对应的方法列表内的参数结构信息。每一个HSF Provider 都会在启动后、每隔一段时间向redis上报元数据，方便运维，元数据存储通过Redis承担
  

• HSF总控制台：将ConfigServer、Diamond、Redis功能进行对接，对用户呈现服务查询、服务治理规则管理、服务测试、服务Mock等，HSF总控制台通过HSFOPS承担，用户可以从此处看到ConfigServer、Diamond、Redis存储的相关信息