认识达内从这里开始

微服务架构开发随着互联网的不断发展而被越来越多的程序员掌握，今天我们就通过案例分析来简单了解一下，微服务架构开发应用实践分享。

自动化测试

微服务将原本大一统的系统拆分为多个独立运行的“微”服务，微服务之间的接口数量增加，并且微服务提倡快速交付，版本周期短，版本更新频繁。因此必须通过自动化测试系统来完成绝大部分的测试回归工作。

自动化测试涵盖的范围包括代码级的单元测试、单个系统级的集成测试、系统间的接口测试，理想情况是每类测试都自动化。

自动化部署

微服务部署频率会大大增加，部署次数会使大一统系统部署次数的几十倍，如果要人工手动部署，需要投入大量的人力，并且容易出错，因此需要自动化部署的系统来完成部署操作。

自动化部署系统包括版本管理、资源管理(例如，机器管理、虚拟机管理)、部署操作、回退操作等功能。

配置中心

微服务的节点数量非常多，通过人工登录每台机器手工修改，效率低，容易出错。微服务需要一个统一的配置中心来管理所有微服务节点的配置。

配置中心包括配置版本管理、增删改查配置、节点管理、配置同步、配置推送等功能。

接口框架

微服务提倡轻量级的通信方式，一般采用HTTP/REST或者RPC方式统一接口协议。但在实践过程中，光统一接口协议还不够，还需要统一接口传递的数据格式。

但在实践过程中，光统一接口协议还不够，还需要统一接口传递的数据格式。

API网关

系统拆分为微服务后，内部的微服务之间是互联互通的，相互之间的访问都是点对点的。

微服务需要一个统一的API网关，负责外部系统的访问操作。

API网关是外部系统访问的接口，所有的外部系统接⼊系统都需要通过API网关，主要包括接入鉴权(是否允许接入)、权限控制(可以访问哪些功能)、传输加密、请求路由、流量控制等功能。

服务发现

需要一套服务发现的系统来支撑微服务的自动注册和发现。

服务发现主要有两种实现方式：自理式和代理式。

1、自理式

自理式结构就是指每个微服务自己完成服务发现

该部分的功能一般都通过统一的程序库或者程序包提供给各个微服务调用，而不会每个微服务都自己来重复实现一遍;并且每个微服务都成端了服务发现的功能，访问压力分散到了各个微服务节点，性能和可用性上不存在明显的压力和风险。

2、代理式

代理式结构就是指微服务之间有一个负载均衡系统，由负载均衡系统来完成微服务之间的服务发现。

实际中该方案存在风险较大：

可用性风险：一旦LOADBALANCER系统故障，就会影响到所有微服务之间的调用

性能风险：所有的服务之间的流量调用都需要经过LOADBALANCER系统，性能压力会随着微服务数量和流量增加而不断增加，后成为性能瓶颈

因此，LOADBALANCER系统需要设计成集群的模式，但集群实现又增加了复杂性

不管是自理式还是代理式，服务发现的核心功能就是服务注册表，注册表记录了所有的服务节点的配置和状态，每个微服务启动后都需要将自己的信息注册到服务注册表，然后由微服务或者LOADBALANCER系统到服务注册表查询可用服务。

服务路由

服务路由一般不会设计成一个独立运行的系统，通常情况下是和服务发现放在一起实现的。对于自理式服务发现，服务路由是微服务内部实现的;对于代理式服务发现，服务路由是由LOADBALANCER系统实现的。无论放在哪里实现，服务路由核心的功能就是路由算法。常见的路由算法有：随机路由、轮询路由、小压力路由、小连接数路由等。

服务容错

常见的服务容错包括请求重试、流控和服务隔离。通常情况下，服务容错会集成在服务发现和服务路由系统中。

服务监控

服务监控的主要作用有：

实时搜集信息并进行分析，避免故障后再来分析，减少了处理时间。

服务监控可以在实时分析的基础上进行预警，在问题萌芽的阶段发觉并预警，降低了问题影响的范围和时间。

通常情况下，服务监控需要搜集并分析大量的数据，因此建议做成独立的系统，而不要集成到服务发现、API网关等系统中。

【免责声明】本文系本网编辑部分转载，转载目的在于传递更多信息，并不代表本网赞同其观点和对其真实性负责。如涉及作品内容、版权和其它问题，请在30日内与管理员联系，我们会予以更改或删除相关文章，以保证您的权益!请读者仅作参考。更多内容请加抖音达内三江区域学习了解。