分布式服务框架(二)

一、分布式服务框架其他组成

  上一节《分布式服务框架(一)》讲述了RPC发展到SOA的过程,常见的SOA服务治理方案,以及分布式系统中常见的专业名词,这部分其实只是涉及到了一个分布式系统架构的轮廓,真正一个系统的构建,还需要很多模块互帮互助,协同工作和其他相关平台的搭建。

  一个大型,稳健,成熟的分布式系统的背后,往往会涉及众多支撑运作的系统,我们统称这部分系统为分布式系统架构中的基础设施,下面将介绍一些常见甚至必用的基础设施。

  (1)CI/CD平台:即持续集成/持续交付,持续集成是指软件个人研发的部分向软件整体部分交付,频繁进行集成以便更快地发现其中的错误,持续交付在持续集成的基础上,将集成后的代码部署到更贴近真实运行环境的「类生产环境」(此解释来自https://blog.csdn.net/eugenelee2096/article/details/73332615)说得这么复杂,无非就是开发代码过程中持续的提交,然后进行持续的代码扫描,单元测试,编译构建,完成如上流水线后迅速的部署到目标环境上允许的过程。

  (2)ConfigCenter:即配置中心,为各应用的所有环境提供了一个中心化的外部配置,为服务端和客户端提供了分布式系统的外部化配置支持。

  (3)Web Portal/IDE:集成应用配置,管理平台的统一入口和开发IDE。

  (4)Deploy Center:部署中心,所有的服务,无论是公共SAAS服务还是业务服务,开发完成后都需部署到对应的区域和环境上,部署中心提供了发布应用包的平台供开发者进行发包部署操作,或提供接口供CI/CD的接入。

  (5)公共SAAS:即整个分布式系统中公用的服务,常见的有权限服务,数据字典,国际化等

  (6)服务注册中心:服务注册中心,是分布式服务系统中的一个重要组成模块,管理Provider的Manager,在实际的运行环境中,服务注册中心Registry被动通知或Consumer主动询问,在Provider有节点宕机或新增节点时,客户端也可实时感知到,从而避免了某个Provider被无限调用或是无限闲置

  (7)Maven,Git仓库管理:Maven仓库用来存储和管理开发和部署应用过程中所需的JAR或ZIP文件,Git用来存储开发者代码,提供了代码合成,分支管理等功能。

  (8)日志中心:服务运行过程中,不可避免的会出现各种问题,如何快速定位并分析清楚这些问题的根因,并提出有效的解决方案,日志在这其中扮演了很重要的角色,日志中心通过收集Consumer或Provider产生的日志,为用户查询下载日志提供了可视化平台。

  (9)监控中心:接收来自Consumer和Provider异步上报的性能监控数据,对有风险的节点发出告警

  (10)事件中心:事件中心是高度可缩放的数据流式处理平台和事件引入服务,可以处理和存储分布式软件和设备生成的事件、数据或遥测

二、完整的分布式系统设计

  以上所述基础设施都是分布式系统中重要或不可缺少的部分,怎么将这些基础设施整合到一起,使整个分布式系统能够协调运作,下面展示了个人对于这方面的理解。

  开发者接入到对应的IDE开发平台,选择对应的产品(Maven或Gradle)构建工程,通过分支管理等措施的落实,进行代码的编写,提交,合并,之后提交CI平台进行代码检查,编译构建,单元测试并部署到部署中心,也可脱离CI进行手动部署。

  不管开发者开发的是公共SAAS还是业务服务,都会通过部署中心部署到对应的环境区域,业务服务从配置中心拉取应用配置信息,将服务注册发布到注册中心,并可任意调用环境中周边的公共SAAS服务。

  服务在运行过程中,将日志以异步消息的形式上传到日志中心,此处也可由日志中心进行主动收集。同时将性能等方面的数据上报到监控中心,监控中心发现异常后,会对用户发出告警。监控中心还包括一个事件上报模块,收集容器的运行状况和产生的事件等数据,对服务的运行作出必要的决策。

  

原文地址:https://www.cnblogs.com/jiyukai/p/9460373.html

时间: 2024-08-28 07:53:19

分布式服务框架(二)的相关文章

基于Dubbo框架构建分布式服务 (二)

Dubbo是Alibaba开源的分布式服务框架,我们可以非常容易地通过Dubbo来构建分布式服务,并根据自己实际业务应用场景来选择合适的集群容错模式,这个对于很多应用都是迫切希望的,只需要通过简单的配置就能够实现分布式服务调用,也就是说服务提供方(Provider)发布的服务可以天然就是集群服务,比如,在实时性要求很高的应用场景下,可能希望来自消费方(Consumer)的调用响应时间最短,只需要选择Dubbo的Forking Cluster模式配置,就可以对一个调用请求并行发送到多台对等的提供方

分布式服务框架下,如何做到服务化最佳实践?

“升级服务框架后,性能.可靠性等问题日益明显.服务化之后面临的诸多挑战,怎样分析才能给出实践最优解? 在服务化之前,业务通常都是本地API调用,本地方法调用性能损耗较小.服务化之后,服务提供者和消费者之间采用远程网络通信,增加了额外的性能损耗,业务调用的时延将增大,同时由于网络闪断等原因,分布式调用失败的风险也增大.如果服务框架没有足够的容错能力,业务失败率将会大幅提升. 除了性能.可靠性等问题,跨节点的事务一致性问题.分布式调用带来的故障定界困难.海量微服务运维成本增加等也是分布式服务框架必须

分布式服务框架 Zookeeper(一)介绍

一.概述 ZooKeeper(动物园管理员),顾名思义,是用来管理Hadoop(大象).Hive(蜜蜂).Pig(小猪)的管理员,同时Apache Hbase.Apache Solr.LinkedIn Sensei等众多项目中都采用了ZooKeeper. ZooKeeper曾是hadoop的正式子项目,后发展成为Apache顶级项目,与Hadoop密切相关但却没有任何依赖.它是一个针对大型应用提供高可用的数据管理.应用程序协调服务的分布式服务框架,基于对Paxos算法的实现,使该框架保证了分布式

Dubbo分布式服务框架入门

参考http://blog.csdn.net/u013142781/article/details/50387583 一.Dubbo概念介绍 1.1.Dubbo是什么? Dubbo是一个分布式服务框架,致力于提供高性能和透明化的RPC(Remote Procedure Call Protocol)远程服务调用方案,以及SOA(Service-Oriented Architecture,面向服务的体系结构)服务治理方案.简单的说,dubbo就是个服务框架,如果没有分布式的需求,其实是不需要用的,只

【转】阿里巴巴分布式服务框架 Dubbo 团队成员梁飞专访

原文链接:http://www.iteye.com/magazines/103 Dubbo是阿里巴巴内部的SOA服务化治理方案的核心框架,每天为2000+ 个服务提供3,000,000,000+ 次访问量支持,并被广泛应用于阿里巴巴集团的各成员站点.Dubbo自2011年开源后,已被许多非阿里系公司使用. 项目主页:http://alibaba.github.io/dubbo-doc-static/Home-zh.htm 为了使大家对该框架有一个深入的了解,本期我们采访了Dubbo团队主要开发人

分布式服务框架(一)

一.RPC RPC(Remote Process Call),即远程服务调用,被广泛地应用在很多企业应用中,是早期主要的服务治理方案,其流程较为简单,客户端consumer携带参数发送RPC请求到服务提供方provider,provider根据参数路由到具体函数,方法,并将执行获得的结果返回,至此一次RPC调用完成. 随着业务的发展,大数据时代的到来,服务提供方的压力也日益增大,单机应用的处理能力无论在软件,硬件上都受到限制,provider也不可能一直无限扩容,即使扩容,也存在着很多问题,即服

分布式服务框架之远程通讯技术及原理分析

在分布式服务框架中,一个最基础的问题就是远程服务是怎么通讯的,在Java领域中有很多可实现远程通讯的技术,例如:RMI.MINA.ESB.Burlap.Hessian.SOAP.EJB和JMS等,这些名词之间到底是些什么关系呢,它们背后到底是基于什么原理实现的呢,了解这些是实现分布式服务框架的基础知识,而如果在性能上有高的要求的话,那深入了解这些技术背后的机制就是必须的了. 1 基本原理 要实现网络机器间的通讯,首先得来看看计算机系统网络通信的基本原理,在底层层面去看,网络通信需要做的就是将流从

一篇文章带你深入了解Dubbo分布式服务框架

一.产生的背景 随着互联网的发展,网站应用的规模不断扩大,常规的垂直应用架构已无法应对,分布式服务架构以及流动计算架构势在必行,亟需一个治理系统确保架构有条不紊的演进.下面我们用一个图来具体说明架构和开发框架的演进过程.单一应用架构当网站流量很小时,只需一个应用,将所有功能都部署在一起,以减少部署节点和成本.此时,用于简化增删改查工作量的数据访问框架(ORM)是关键. 垂直应用架构当访问量逐渐增大,单一应用增加机器带来的加速度越来越小,将应用拆成互不相干的几个应用,以提升效率.此时,用于加速前端

开源|ns4_frame分布式服务框架开发指南

导语:宜信于2019年3月29日正式开源nextsystem4(以下简称"NS4")系列模块.此次开源的NS4系列模块是围绕当前支付系统笨重.代码耦合度高.维护成本高而产生的分布式业务系统解决方案.NS4系列框架允许创建复杂的流程/业务流,对于业务服务节点的实现可串联,可分布式.其精简.轻量,实现了"脱容器"(不依赖tomcat.jetty等容器)独立运行.NS4系列框架的设计理念是将业务和逻辑进行分离,开发人员只需通过简单的配置和业务实现就可以实现逻辑复杂.性能高