调用端依赖的服务个数及每个服务的实例数越来越多,造成调用端的启动越来越慢;
当前的软负载均衡策略遇到挑战,急需优化、调整;
跨应用、跨系统的调用越来越多,调用关系和依赖关系日益复杂,可观察性越来越差;
混合部署需要支持多注册中心,不同的服务访问不同的注册中心;
各服务的信息比如入参/出参等散落在各个地方,服务调用者无法快速、准确、全面获取这些知识,沟通成本非常高;
跨语言支持日益迫切,基于库方式将开发者绑死在单一技术栈上,与微服务理念相悖;
缺乏灵活、智能、贴近业务场景及业务架构的流量控制机制及相应的运维支持手段;
缺乏灵活、适度的安全机制;特性增加与BUG修复升级非常困难。
检索
除了支持按基本属性查询外,还支持按扩展属性查询;除了支持模糊查询外,还支持按类目查询,比如按“交易类”、“商家类”、“金融类”、“物流类”等类目进行查询。
知识库
提供全方位、多维度的服务知识,除了提供服务基本的出/入参数详情、负责人等组织架构信息外,还提供了服务当前的运行指标数据,比如QPS/TP情况/可用率等;提供服务档案(包括已经终止的服务),记录某服务生命周期各阶段的情况,包括版本变化及各版本对应的接口服务详细信息,以方便事后审计;提供服务快照功能,方便把服务在某个时刻的状态记录下来,比如大促时刻的状态。
权限认证
提供相关的流程控制,比如调用申请、服务终止申请、服务访问授权等;
质量跟踪
提供服务重要性评估、服务健康度评估、服务架构合理性评估,并提出相应建议;
调用关系
结合微服务调用图谱,提供服务的调用链信息,以便了解服务的相关依赖关系及链路属性;
资源评估
提供资源使用情况,以配合相关人评价该服务是否有足够能力满足新的调用需求;还提供测试环境,以供临时测试体验,而不需要去挨个找对应服务的测试环境;
评价互动
提供服务输出者和使用者的互动功能;整合相关系统上对服务的评价信息,给服务使用者更加全面的知识。
来源分析:分析某服务的直接调用者的情况
入口分析:分析某服务的最初调用者(入口)的情况
路径分析:分析一条完整调用链的情况
耗时分析:分析一条调用链中的各个环节的耗时情况
瓶颈分析:分析一条调用链中的瓶颈点的情况
依赖度分析:分析一条调用链中的强依赖、若依赖等的情况
流量控制中要支持“版本”的概念(比如在一个分组中有两个版本,现在需要对其中一个版本的实例进行操作);
提供平滑的灰度升级和回退手段,支持A/B测试、金丝雀部署等;
支持动态配置(不需要反复修改程序-打包-重新上线),这些动态配置的取值往往不可预测,需要根据实际情况随时调整,比如流量的阈值、服务超时时间等;
服务永久下线的全流程支持(经常有业务为了下线一个即将废弃的服务,而一遍遍的发邮件确认是否有人还在调用该服务);
临界条件下的强制降级、限流和熔断等;
废弃接口的治理,将长期没有调用量的接口,定期给相关人发通告,让他们下线。必要时,可以主动将它们下线,然后回收相应的资源。
增加更多的探针
在通信过程的各个环节(编解码、序列化等)加入探针逻辑,并通过开关控制,当出现诸如性能问题时,可以打开开关,通过探针逻辑输出的日志来定位瓶颈点;没有问题时,将开关关闭,避免影响性能。
增加更多的扩展点
在诸如序列化、路由决策等地方,提供扩展点,允许用户提供定制的功能实现,来满足他们的个性化需求。
开发新通信协议
开发新一代的TCP通信协议,加强协议头部的能力,并加入握手阶段,解决很多控制方面的短板,比如安全认证、路由等。
增加相关注解
提供跟服务接口相关的注解,自动收集服务接口信息,为微服务集市收集数据,以降低手动录入的工作量。
支持服务扩展属性
当前JSF服务的属性是固定的,不允许用户扩展属性,由此引发了一个深层次问题:业务只能按照JSF的规则来组织服务关系,而不能自定义服务关系,带来的后果就是一旦业务场景或业务架构跟JSF组织的服务关系不匹配,就会出现本来彼此相关的一系列服务被割裂的现象,业务只能逐个处理,而不能整体处理,就像下图所示的那样:
左边是个单体应用,一共由4个彼此依赖的服务构成,当该应用需要下线时,4个服务会同时下线(因为它们在同一进程空间中);而在右边,它们被微服务化,由不同开发小组来维护,当一个服务需要下线时,实际上需要其他服务一起下线,从而构成一个“有机的微服务集”,此时只能靠扩展属性,将它们“逻辑”地绑定在一起,进行整体下线,否则只能一个个下线,非常麻烦,效率低还易出错。通过该功能特性,使得用户能自由、灵活地按照实际的业务场景或架构来组合形成“有机的微服务集”,进行整体操作,从而提高效率。