微服务框架的不足

发表于

如果从服务构建到生产运营，包括的技术有：微服务框架，容器化，持续集成与发布，资源调度与服务编排，监控等一些大的范围。

微服务框架的不足

上一篇文章主要对服务框架的相关技术做了整理，也输出了一个Spring Cloud的微服务框架实践。其中，也发现了一些问题和不足，接下来讨论下目前微服务框架的不足和对应的优化方案，主要以Spring Cloud为主进行说明

多语言支持

企业里的应用可能是由多种编程语言来构建的，微服务框架就需要考虑支持多语言，目前有以下这些方式：

  1. 客户端SDK嵌入支持
  2. http接口支持，需要应用再次集成
  3. sidecar模式支持
  • Spring Cloud
  1. 主要提供了java SDK 的支持，其它语言如果要接入该体系，需要用注册发现的http接口来集成，这种方式并不有友好。
  2. spring cloud netflix sidecar 是Spring Cloud提供的服务网格组件，便于非java语言的接入。相对http接口的方式变得简单。
  3. consul服务发现支持DNS功能，所以非Java客户端服务调用依赖consul DNS功能也是一种更简单的方式。
  4. 使用 Service Mesh 服务网格框架，为每个应用创建一个独立的代理，由代理完成服务治理的工作。

面向业务

上一篇讲了微服务框架的技术，实际上这么多技术就是为了解决服务治理的工作，如果业务开发人员要清楚这么多细节，那么可能需要很长一段时间。
所以，需要做到让业务开发人员专注于业务，降低开发门槛，提高微服务的开发效率是框架必须要做到的。

SDK

SDK就是传统直接依赖代码的方式，好处是灵活，并且容易自主可控。如果是非多语言环境，目前还是最好的选择。
但是，应用端耦合了SDK，微服务框架目前发展变化快，所以应用端需要关注更多的服务治理相关的内容。其次，SDK依赖随着功能的增加也越来越大，会增加构建，部署，启动的时间。
当然，这种方式仍有很多优化空间，并且是一种可行的实践方式。

Service Mesh

A service mesh is a dedicated infrastructure layer for handling service-to-service communication. Consists of a control plane and data plane (service proxies act as “mesh”). - William Morgan, What’s a Service Mesh? And Why Do I Need One?

服务网格也是微服务发展的一个产物，可以把服务治理的工作放在一个单独的Proxy上，让业务模块小且专注。解决了微服务技术门槛高,多语言支持不足,代码侵入性强的问题。目前的服务网格框架有：
Linkerd、Envoy、Istio、NGINX Application Platform、Conduit…
最近，Istio发布了1.0版本，这也许意味着微服务开始进入2.0时代。
如果使用Service Mesh，那么可能将需要引入容器，服务调度K8s平台等做微服务体系相关的支持。

FAAS 面向函数

把业务单元拆的更彻底，只需要面对业务逻辑方法，然后在FAAS平台上部署。更不需要关注云环境和运行时资源，可以根据服务请求量和运行态动态伸缩底层资源。
这是一种更理想的情况，带来运行成本更低，自动扩缩容，事件驱动等特性，目前AWS， 阿里云等也在快速布局和发展。
可能需要关注的问题是：

  1. 利用冷启动实现的资源的按需分配，如果是java启动速度需要关注
  2. 资源的掌控是不够，特殊应用需要特殊配置
  3. 函数之间的调用和管理

Spring Cloud　Finchley 版本提供了　Spring Cloud Function模块对面向函数提供了支持。

服务治理动态调整

微服务对外限流降级，对内调用负载均衡，熔断降级，那么，根据每个微服务的运行时指标监控，还可以动态控制调整服务治理，主动及时做出变化。

  • 负载均衡
    根据服务调用的指标，将不正常服务剔除，或根据RT，超时等自动调整权重等。
  • 限流
    根据服务自身的指标，和RT时间等，动态调整限流的量，来更好的保护服务和保证RT响应时间；
    服务的调用方往往有多个，所以，服务端需要更精确的限流来分配流量；
    根据依赖服务的能力，动态的分配这个能力给调用方做限流。
  • 熔断
    调用时的熔断与恢复，也可以根据服务方的指标来做动态的调整，这要比尝试一定次数更好些。

当然，配合指标监控，服务治理可以优化的空间还很多。

微服务其它相关技术支撑

标准构建物-容器镜像

Docker提供了应用标准化的构建和运行的能力

持续集成与发布

CI持续集成来验证每一次提交的正确性
CD提供各种部署的能力，如滚动，蓝绿，灰度发布等

资源管理与调度编排

资源管理

管理集群机器资源，包括异构和不同配置的主机

调度编排

将服务编排到合适的资源上，还包括服务之间的依赖关系配置，自动伸缩等

基础服务抽象

管理容器之外的应用，提供抽象和代理非容器化的软件

自动伸缩，自愈

AutoScale可以根据cpu、内存、请求数等条件，自动增加或减少服务数量。

监控

微服务场景下的监控将变得更加重要,包括：基础设施，真实请求，主动探测，服务指标，调用指标，调用链，日志收集，异常配置与检测，告警等。