服务调用几个误区 - 需要区分通信框架的NIO，不等于上层应用调用的异步，2个完全是不同角度，不是一个层面的事情，即使是底层通信的NIO也可以实现上层同步调用服务的功能；
- NIO的好处：
关于这个看之前那章里面推荐文章。 3.服务调用和通信框架的关系 这里是通过中间的消息队列来实现隔离上层同步异步跟底层通信框架的IO解耦的，现实中会去掉消息队列，使用future模式来实现。 - 现在rpc这么普及，应该不会有人还存在这种观点了吧；
- OneWay模式，只有请求没有应答：
3.请求-应答模式： 异步调用性能更高：个人觉得首先要想清楚为什么需要异步，需要分布式，而不是单纯考虑那个性能更好。 调用方式 异步
- 泛化，框架提供通用接口方法，应用实现具体服务，然后发布和引用
服务注册中心统一管理服务注册发布和订阅。 概念 - 高HA：支持数据持久化，支持集群；
- 数据一致性问题；
- 数据变更主动推送。
关键功能特性设计 - 服务提供者在启动时，根据配置，向注册中心发布服务相关信息；
- 服务消费者启动时，根据配置，向注册中心订阅所需服务，本地缓存；
- 注册中心返回服务提供者信息给消费者，如有变更，主动推送消费者，消费者刷新本地缓存；
- 服务消费者根据本地缓存的服务提供者地址列表，选择相应提供者进行调用；
- 链路的安全性：指的是注册中心与客户端连接的安全认证，基于IP的黑白名单或基于用户名+密码或基于秘钥+数字证书的认证；
- 数据安全性：指的是数据的权限控制：
发布订阅机制：除了启动时的发布订阅，最关键的是动态发布订阅的支持； - 可靠性：注册中心集群部署，任意一台宕机，不影响注册中心的使用，集群不可用，只会影响新服务的发布订阅，不影响已缓存服务的使用。
基于zk的服务注册中心设计 服务发布和引用服务提供者需要支持通过配置、注解、api接口调用等方式发布服务，同理，服务消费者也可以通过这些方式引用服务。 服务发布 - xml配置，注解，api接口调用
本地实现类封装成代理，其好处： - 发布流程享受，通过抽象代理层，可对服务发布行为本身进行封装和抽象；
- 通过动态代理，可对服务发布进行动态拦截，方便对服务发布定制；
- 扩展和替换；
- 供消费者订阅服务地址信息；
- 基于注册中心的统一服务治理；
- 服务注册的目录结构可以按照主机、服务名、url来，按实际需求判断，例如按主机来：
感觉少了一步，在完成服务注册后，服务提供者需要启动监听，等待服务调用。 服务引用 - 本地接口调用转换成远程服务调用，主要是根据配置或注解的远程服务信息，生成服务的动态代理；
- 服务地址本地缓存，在生成动态代理之前，就会根据引用的服务信息，连接注册中心，获取服务相关配置信息和服务提供者列表，缓存到本地，后期就可以直接在本地查询。
- 远程服务调用，从本地缓存列表获取服务提供者地址信息，根据路由策略，选择链路，然后就是一系列的服务治理，最后远程调用。
最佳实践 - 对等设计：服务的发布或引用，配置支持的，必须也能够通过注解或api接口实现支持；
- 启动顺序，主要是服务提供者、注册中心、服务消费者3者的系统启动顺序无法控制，其实最主要的是要支持注册中心的断连重连机制，客户端（提供者和消费者）和注册中心定时通信，发布或获取服务信息，这样就无所谓启动顺序；
- 同步还是异步发布服务，这个主要是服务太多了，如果系统启动时，就发布服务，会影响启动时间，看需求吧；
- 警惕网络风暴，对于注册中心，可能需要注册的服务太多或者服务变更频繁，挤占注册中心网络带宽，需要考虑的是那些信息需要向注册中心同步；
- 配置扩展，主要是发布或引用需要支持扩展。
服务灰度发布作用参考AB测试，保证系统的稳定性前提下，灰度发布解决升级后的兼容性问题。 流程设计
- 灰度规则设置，这个更多的是灰度路由规则，将流量引入灰度环境；
没搞过这些流程，而且，服务发布可以只发布部分集群，然后为集群配置路由规则引入流量，所以对这一块没想太深入。 参数传递服务消费者和提供者之间的交互通信，除了正常的业务参数，可能需要携带额外的信息，如消费者的ip地址，调用链的ID等，要保证这些额外信息不影响正常业务参数，即使有线程切换的场景发生。 作者说这些额外参数不能通过业务接口来进行传递，需要框架支持这种参数传递，不太同意，正确的说应该不要影响正常业务接口参数即可。 内部传参 - 硬编码，api接口传参，也可以通过ThreadLocal传递（无线程切换场景）；
- 业务编排引擎对业务进行编排，参数通过编排上下文进行；
- 专业的BPM流程引擎进行编排，流程上下文传递参数；
- 服务框架内部参数传递，内部模块可能发生线程切换，可以直接把所有参数带上，也可以通过将一次调用的参数放入框架的context中，后续参数从其中取值；
外部传参 - 通信协议支持，参考之前的协议设计，在自定义协议中，支持参数的扩展；
- 传参接口定义，框架提供接口，用于跨进程的参数传递，通过context线程变量供传参使用。
最佳实践 - 防止参数互相覆盖，框架的参数不能覆盖业务参数；
- 参数的生命周期管理，主要是放入context的变量，要记得在调用完成或异常等场景下清理。
服务多版本服务上线后的功能变更，bug修复，需要多版本管理。 服务多版本管理设计 - 服务提供者：发布时，支持指定服务的版本号；
- 服务消费者：消费服务的时候，支持指定引用的服务版本号或版本范围。
- 服务版本号管理，主版本+副版本+微版本
- 服务提供者，服务消费者：
- 服务提供者，发布服务的时候，指定版本号，对于经常变动的服务，单独部署发布；
- 服务提供者引用服务时指定版本号或版本范围；
与OSGI的对比 淘宝的HSF基于osgi，挺牛，能把osgi玩好的不容易。 osgi基于插件管理，支持热部署和热升级，参考eclipse的插件体系。 不使用osgi的原因很多，最主要的就是学习成本太高，不易理解，实现复杂，而他的有点又可以通过其他技术解决，所以除了淘宝的HSF实在没听说太多应用。 服务的多版本管理感觉就是发布服务和引用服务的时候需要指定版本，不能单靠服务的多版本解决问题兼容性问题，更多的关注点应该放在服务本身的兼容性设计上。 |
