- 《架构世界》2020金融刊：DevOps与微服务在金融业的应用
- 普元信息
- 4447字
- 2025-02-17 06:23:30
三、微服务架构关键技术
微服务平台技术图谱
微服务技术桟：
:
:
基础框架：
微服务容器：
服务发布：
服务注册中心： -
服务路由： -
服务调用： -
服务熔断器： -
安全认证： -
服务配置中心：, -
服务监控：
关键技术架构与设计
我们从这个方面来解析微服务关键技术架构与设计。
、前端框架
兼容性
是流行的前端框架，其对浏览器的兼容性较好，主流的操作系统和浏览器都支持。
响应式双向数据绑定实现自动同步
.采用数据劫持结合发布者-订阅者的方式，通过.（）来劫持各个属性的，，在数据变动时，发布消息给订阅者，触发相应的监听回调。
具体的来讲，.通过指令去对做封装，当数据发生变化，会通知指令去修改对应的，数据驱动的变化。.还会对操作做一些监听（ ），当我们修改视图的时候，.监听到这些变化，从而改变数据。这样就形成了数据的双向绑定。
、微服务容器
微服务运行的容器环境
我们来看一下微服务运行容器，要做可靠高效的微服务架构应用，实际上我们需要做的事情还是非常多的。如果没有一个统一的微服务容器，这些能力在每个微服务组件中都需要建设一遍，而且会五花八门，也很难集成到一起。
微服务容器：负载均衡
微服务容器的基础服务能力之一就是支持负载均衡。
. 通常所说的负载均衡都指的是服务端负载均衡，其中分为硬件负载均衡和软件负载均衡。硬件负载均衡主要通过在服务器节点之间安装专门用于负载均衡的设备，比如等；而软件负载均衡则是通过在服务器上安装一些具有负载均衡功能或模块的软件来完成请求分发工作，比如等。
. 硬件负载均衡的设备或是软件负载均衡的软件模块都会维护一个下挂可用的服务端清单，通过心跳检测来剔除故障的服务端节点以保证清单中都是可以正常访问的服务端节点。当客户端发送请求到负载均衡设备时，该设备按照某种算法（比如线性轮询、按权重负载、按流量负载等）从维护的可用服务端清单中取出一台服务端的地址，然后进行转发。
. 客户端负载均衡和服务器负载均衡最大的不同点在于上面所提到的服务清单所存储的位置。在客户端负载均衡中，所有客户端节点都维护着自己要访问的服务端清单，而这些服务端的清单来自于服务注册中心，建议使用 的组件。
微服务容器：服务熔断、容错、升降级、限流
微服务容器的基础服务能力之二就是服务熔断、容错、升降级、限流，在系统出现异常时提供故障恢复能力。
、注册中心
服务注册与发现
接下来我们聊一下注册发现，以前的单块应用之间互相调用时配置个就行了，但在微服务架构下，服务提供者会有很多，手工配置地址又变成了一个不可行的事情。那么服务自动注册发现的方案就解决了这个问题。
我们的服务注册发现能力是依赖 组件实现的。服务在启动的时候，会将自己要发布的服务注册到服务注册中心，运行时，如果需要调用其他微服务的接口，那么就要先到注册中心获取服务提供者的地址，拿到地址后，通过微服务容器内部的简单负载均衡器进行路由。
一般情况，系统内微服务的调用都通过这种客户端负载均衡的模式进行，否则就需要有很多的负载均衡进程。跨业务系统的服务调用，也可以采用这种去中心化的路由方式。当然采用的模式，由中心化的服务网管来管理系统间的调用也是另一种选择，要结合企业的现状和需求来决定。
、配置中心
集中配置管理
微服务分布式环境下，一个系统拆分为很多个微服务，一定要告别投产或运维手工修改配置的方式。需要采用集中配置管理的方式来提升运维的效率。
配置文件主要有运行前的静态配置和运行期的动态配置两种。静态配置通常是在编译部署包之前设置好。动态配置则是系统运行过程中需要调整的系统变量或者业务参数。
要想做到集中的配置管理，那么需要注意以下几点：
. 配置与介质分离，这个就需要通过制定规范的方式来控制。千万别把配置放在包里。
. 配置的方式要统一，格式、读写方式、变更热更新的模式尽量统一，要采用统一的配置框架
. 运行时需要有个配置中心来统一管理业务系统中的配置信息，这个就需要平台来提供配置中心服务和配置管理门户。
配置修改同步交互
配置修改后通过推送或者定时拉取的方式更新并缓存到应用程序所在的微服务容器中供应用程序使用。
高可用运行架构设计
配置中心有两种部署模式
. 高可用模式，见上图，支撑大规模微服务访问时根据负载情况可以对“配置查询同步服务”进行横向扩展
. --模式，配置变更服务、配置查询服务合并为一个进程。适合支撑少量系统的场景使用。
配置中心可以支持高可用模式部署，满足金融行业的要求。
、监控中心
基于定制实现
主要就是通过收集各种格式的数据进行存储，然后展示。所以我们需要关注的是 、 和存储设备。
探针
是 .以后引入的，也可以叫做代理。
是运行在方法之前的拦截器，它内定的方法名叫，也就是说先执行方法然后再执行方法。
使用技术构建一个独立于应用程序的代理程序（即为），用来协助监测、运行甚至替换其他上的程序。使用它可以实现虚拟机级别的功能。
全链路运行监控
调用链跟踪分析：把同一的收集起来，按时间排序就是。把串起来就是调用栈。
实时分析：对单条日志直接分析，不做汇总，重组。得到当前，延迟。
离线分析：按汇总，通过的和还原调用关系，分析链路形态。
、日志中心
日志中心架构
日志分析是运维工程师解决系统故障，发现问题的主要手段。日志主要包括系统日志、应用程序日志和安全日志。系统运维和开发人员可以通过日志了解服务器软硬件信息、检查配置过程中的错误及错误发生的原因。经常分析日志可以了解服务器的负荷，性能安全性，从而及时采取措施纠正错误。
通常，日志被分散的储存在不同的设备上。如果你管理数十上百台服务器，你还在使用依次登录每台机器的传统方法查阅日志，即繁琐又效率低下。为此，我们使用集中化的日志管理，将所有服务器上的日志收集汇总。
集中化管理日志后，日志的统计和检索又成为一件比较麻烦的事情，这时实时日志分析平台能够完美的解决上述的问题，由、和三个开源工具组成。
规范日志与流水，问题追根溯源
作为一个微服务应用平台除了提供支撑开发和运行的技术组件和框架之外，还应该提供一些运维友好的经验总结，我们推荐的日志与流水实现如下：
. 先来看日志，平台应提供的日志主要有三种，系统日志，引擎日志还有跟踪日志。有了这些日志，在出问题的时候能够帮助我们获取一些关键信息进行问题定位。
. 要想做到出了问题能够追根溯源，那么右边的这些流水号的设计也是非常重要的，日志与各种流水号配合，能够让我们快速定位问题发生的具体时间地点以及相关信息，能够快速还原业务交易全链路。对这些日志与流水的细节处理，对于系统运维问题定位有非常大的帮助，没有这些有用的日志内容，日志收集套件搭建的再漂亮，收一堆垃圾日志也是没用的。
通常开源框架只是提供个框架由开发人员自由发挥，而设计一个平台则一定要考虑直接提供统一规范的基础能力。
、
基于 的组件定制实现
异步非阻塞模式启动的线程很少，基本上一个 上只需启一个处理线程，它使用的线程资源就很少，上下文切换（ ）开销也少。非阻塞模式可以接受的连接数大大增加，可以简单理解为请求来了只需要进队列，这个队列的容量可以设得很大，只要不超时，队列中的请求都会被依次处理。
逻辑架构
网关就像整个系统的门面一样，所有的外部访问都经过它实现调度、过滤、请求路由、负载均衡、校验等等。
功能
网关上还可以实现更多更复杂的功能。
、（ ）
架构
为企业提供统一的账号管理视角，对所有基于账号的管理、认证、授权、审计进行集中的统一管理，提高了账号管理的安全，帮助系统管理员提高了工作效率，降低了管理负担，同时改善了普通用户在不同资源中登录认证的重复繁琐过程，为日常工作提供了更高的安全性。
统一用户中心
可以为企业所有的资源使用人员如普通用户、系统管理人员、驻场代维人员、合作伙伴、临时工作人员等定义主账号，按照公司的组织方式对人员进行管理。通过一对一的主账号管理模式，可以在该平台实现对所有资源使用人员进行集中定义、集中维护等生命周期管理。
统一认证与鉴权
安全认证方面，我们基于 结合再加上（ ）做安全令牌，实现统一的安全认证与鉴权，使得微服务之间能够按需隔离和安全互通。认证鉴权一定是个公共的服务，而不是多个系统各自建设。
、微服务管理
服务管理机制
• 服务提供者：
. 服务注册
在服务注册时，需要确认下..--=参数是否正确，默认为，若设置为将不会启动注册操作。
. 服务同步
由于服务注册中心之间因互相注册为服务，当服务提供者发送注册请求到一个服务注册中心，它会将该请求转发给集群中相连的其他注册中心，从而实现注册中心之间的服务同步。
. 服务续约
..----参数用于定义服务续约任务的调用间隔时间默认秒。
..----参数用于定义服务失效时间，默认为秒。
• 服务消费者：
. 获取服务
当我们启动服务消费者时候，它会发送一个请求给服务注册中心，来获取上面注册的服务清单。为了性能考虑， 会维护一份只读的服务清单来返回给客户端，同时该缓存清单会每隔秒更新一次。
. 服务调用
服务消费者在获取服务清单后，通过服务名可以获得具体提供服务的实例名和该实例的元数据。因为有这些服务实例的详细信息，所以客户端可以根据自己的需要决定具体调用哪个实例。
单服务异常导致雪崩
采用微服务架构后，服务之间会有错综复杂的依赖关系，例如，一个前端请求一般会依赖于多个后端服务。
在微服务架构中，存在着那么多的服务单元，若一个单元出现故障，就很容易因依赖关系而引发故障的蔓延，最终导致整个系统的瘫痪，造成所谓的雪崩效应，这样的架构较传统架构更加不稳定。
自我保护
当网络分区故障发生时，微服务与 之间无法正常通信，而微服务本身是正常运行的，此时不应该移除这个微服务，所以引入了自我保护机制。
服务注册到 之后，会维护一个心跳连接，告诉 自己还活着。 在运行期间，会统计心跳失败的比例在分钟之内是否低于%，如果出现低于的情况， 会将当前的实例注册信息保护起来，让这些实例不会过期，尽可能保护这些注册信息。
服务容错处理
. 资源隔离：包括线程池隔离和信号量隔离，限制调用分布式服务的资源使用，某一个调用的服务出现问题不会影响其他服务调用
. 降级机制：超时降级、资源不足时（线程或信号量）降级，降级后可以配合降级接口返回托底数据。
. 熔断：当失败率达到阀值自动触发降级（如因网络故障／超时造成的失败率高），熔断器触发的快速失败会进行快速恢复。
. 缓存：提供了请求缓存、请求合并实现。
推荐阅读
关于作者：黄豆，普元信息数字化金融研究院研究员，擅长系统分析和架构设计、金融三级密钥安全体系及信息安全保障、虚拟化和云计算技术、技术；参与研发的神州商桥电子商务平台获得“全国电子商务示范单位”称号；带领团队研发的国电通云终端系统在国网多个省公司推广应用。