展开

关键词

服务架构实践

服务架构实践 2018-3-26 张子阳 推荐: 1 难度: 3 ? 最近想更新一下后台架构方面的知识,因为当前“微服务”是比较流行的一个发展趋势,于是就买了这本书学习一下。 书中的微服务的例子是用Ruby下的Grape框架来实现的,Ruby相对小众,多少也会有点不适应。 读完这本书,最大的收获可能是了解到构建微服务的系统需要用到哪些技术,至于这些技术的详情,还需要通过别的资料来学习。 日志聚合 Splunk(其他:LogStash) 监控告警 Nagios(其他:Ganglia、Zabbix、NewRelic),Nagios本身已包含告警功能;业界还有更强大的告警工具,PagerDuty 持续集成 Jenkins 服务测试 Pact框架 感谢阅读,希望这篇文章能给你带来帮助!

35320

服务信的架构实践

作者|许家滔 编辑|田光 微服务的理念腾讯一直倡导的“大系统小做”有很多相通之处,本文将分享信后台架构服务发现、通信机制、集群管理等基础能力与其上层服务划分原则、代码管理规则等。 过去几年,信都是很敏捷地在开发一些业务。所以我们的底层架构需要支撑业务的快速发展,会有一些特殊的需求。 另外,目前整个信团队已经有一千多人了,开发人员也有好几百。 我们一直在说“大系统小做”,联想一下,微服务腾讯的理念有哪些相同不同的地方呢?通过对比,最终发现还是有许多相通的地方。所以我挑出来讲讲我们的实践。 早年我们 QQ 邮箱、信、图像压缩、反垃圾都是一个 web 服务,只有存储层会独立到后面去,甚至用 web 直连 MySQL。因为它早期比较小,后来变大之后就用微服务架构。 2011 年起负责信后台基础架构,包括分布式存储平台和后台服务框架等,覆盖信账号 / 消息 / 朋友圈核心存储等,并为公众号 / 信支付 / 信企业号等等业务提供组件支持,近两年专注于后台服务质量提升和高性能架构

2.3K30
  • 广告
    关闭

    腾讯云精选爆品盛惠抢购

    腾讯云精选爆款云服务器限时体验6.6元起,还有更多热门云产品满足您的上云需求

  • 您找到你想要的搜索结果了吗?
    是的
    没有找到

    服务架构深度解析最佳实践

    关注于互联网电商,金融,支付等系统领域,10多年研发管理和架构经验,对于中间件、SOA、微服务,以及各种开源技术非常热衷,活跃于Dubbo,Fastjson,Mule,ActiveMQ等各类开源社区。 微服务架构的概念,现在对于大家应该都不陌生,无论使用 Apache Dubbo、还是 Spring Cloud,都可以去尝试微服务,把复杂而庞大的业务系统拆分成一些更小粒度且独立部署的 Rest 服务。 现有的条件下到底要不要做微服务服务拆分成什么粒度才是合适的?遗留的老系统需要如何考虑重构改造?有哪些坑需要我们注意?系统怎么在分布式服务下实现数据的一致性和服务的高可用可伸缩? 本文将从这些问题的深度分析出发,阐述微服务架构落地的一些设计原则和利弊取舍,结合微服务架构过程的很多最佳实践经验,希望给读者带来一定的启发和思考,避免在实际应用过程中走弯路,能够多快好省的落地实现微服务架构 内容涉及: 微服务架构的发展过程简介 微服务架构的特点常见特性 使用微服务架构的常见技术简单示例 微服务架构存在的一些问题 如何合理拆分微服务 遗留系统应该如何改造 怎么考虑拆分后的数据一致性 系统和服务的高可用可伸缩如何实现

    28620

    服务架构实践 学习笔记(1)

    参考:微服务架构实践 第二章 微服务架构的“”应该遵循的两个基本前提: 业务独立性。应该保证微服务是具有业务独立性的单元,并不能只是为了。 另外,每个服务都需要部署带来的健康监控、错误回滚、日志分析等,成本也会显著增加。换句话说,部署运维的成本会随着服务的增多呈指数级增长。因此在微服务实践过程中,对持续交互和部署流水线的要求较高。 微服务实践将促使企业或者团队不断寻找更高效的方式完成基础设施的自动化以及DevOps运维能力的提升。 演进式架构,微服务架构将一个复杂应用拆分成多个服务,每个服务都是一个独立的、可部署的业务单元。 微服务实施过程中需要考虑的因素包括: 分布式系统的复杂度 运维成本 部署自动化 DevOps组织架构 服务间依赖 服务间依赖管理 分布式系统的复杂度主要包括以下几点: 性能。 同传统的单块架构相比,分布式系统由于组件组件的调用时跨进程、跨网络的调用,因此,必然要考虑网络延迟以及宽带的影响。尤其要考虑,当某业务场景需要多个服务相互协作时,响应时间以及性能对系统的影响。

    20020

    服务架构实践

    作者:赵计刚 来源:http://www.cnblogs.com/java-zhao/p/5538232.html(点击文末阅读原文前往) 一、微服务架构图: ? 我将会用到上图中的如下技术 服务注册和服务发现:consul 服务健康检查:consul 配置管理:consul、archaius 集群容错:hystrix 计数监控:codahale-metrics、 :redis实现和consul实现 本地缓存:guava cache 链路跟踪:zipkin、brave 基本技术:springboot 安全鉴权:auth2、openId connect 自动化构建部署 注意:对于服务发现而言,consulServer会通过gossip协议将服务器数据广播给各个本地consul agent(通常是consulClient),所以我们不需要做本地缓存,当被调用服务服务器列表发生改变时 在后续的代码编写过程中,会逐步通过java语言实现一个微服务的整体架构代码。

    61661

    服务领域驱动设计,架构实践总结

    ;下面围绕两种方式的实践去详细分析。 二、微服务架构 1、架构设计 系统的架构设计是一件极度复杂的事情,在工作的这几年大致经历过如下几个阶段:单服务、多服务集群、微服务、持续集成;在近2年比较稳定的选型是微服务+自动化集成的模式: 思考其本质的变化逻辑 3、工程实践 领域模型在代码工程的实践中,可以将不同的子域集成到各自的服务中,也可以在一个服务中,通过多个模块(Module)进行隔离维护,即一个模块对应一个界限上下文; 将业务问题进行分模块分层分包的方式进行隔离 四、实践总结 最后来讨论一些架构实践的经验,随着技术的不断发展和更新换代,为解决业务问题提供了极大的便利,不管是单服务中各种成熟的组件,又或者分布式中的微服务体系,或者聚焦业务管理的领域模型;每种架构选型都有其适用的场景 ,不同的选型意味着不一样的实现成本; 实际上在做架构选型时,成熟有经验的主导者,都极其擅长做折中处理,也就是常说的退一步海阔天空;通常需要考虑团队的综合水平业务需求和产品设计,当然在实际的协作流程中多方都是需要相对让步的

    9520

    「微服务架构」Medium的微服务架构实践

    由于多个服务协调的复杂性和成本(有时跨多个团队),分布式单片系统通常比集中式单片系统差得多。 与此同时,了解微服务不是什么很重要: 微服务不是具有少量代码行或“”任务的服务。 解耦“建立服务”和“运行服务” 如果构建微服务很难,那么运行服务往往更难。当运行服务构建每个服务相结合时,它会减慢工程团队的速度,团队必须不断重新发明这样做。 我们希望让每项服务都专注于自己的工作而不用担心如何运行服务的复杂问题,包括网络,通信协议,部署,可观察性等。服务管理应该每个服务的实现完全分离。 将“构建服务”和“运行服务”分离的策略是使运行服务任务服务技术无关,并且使自己的意见,以便应用工程师可以完全专注于每个服务自己的业务逻辑。 这使得将一大块业务逻辑剥离到单独的服务相对容易,只要新服务提供原始实现相同(高级)的接口即可。 我们的整体应用程序在较低级别封装了数据存储详细信息。

    24221

    服务架构实践服务注册发现中负载方案选型

    服务架构不是银弹,在微服务架构中,我们将面临很多新的问题,这时候势必会引入一个服务注册发现问题。本文作者向大家介绍了随着负载均衡位置的不同,三种主要的服务注册发现和负载均衡方案。 1.微服务架构服务注册发现机制 随着微服务架构深入人心,越来越多的企业将微服务架构付诸实践。 无法知道另一个微服务的具体地址;由于每个服务属于""服务,每个服务生命周期不长,每个服务可能随时被关闭、重启、替换;在随着访问量增加的时候,微服务需要扩容,访问量减少时,微服务需要缩容;这样就导致每个微服务的地址在动态变化 3.新一代的选择 前面说了那么多,对于服务注册发现,在普元新一代数字化企业云平台中,我们是怎么实践的? (图6 新一代服务注册发现架构图) 服务提供者在启动时,将当前应用的域名注册到服务注册表,客户端通过服务注册表拿到服务提供者的服务域名,客户端通过dns解析到Cluster IP,然后发起调用。

    616110

    服务架构选型实践

    背景 随着公司一年多的成长,我们已经开发了数十个项目了,后台有 JAVA 的有 PHP 的,为了更好地提升开发管理效率,各技术大牛小牛们时常进行激烈的 PK,碰撞出了许许多多爱的火花,比如其中之一:微服务实践 设计 系统架构 ? 微服务开发架构.png 只需要有一套 BASE 微服务,BASE 微服务生成业务系统微服务实例,供各个业务系统调用;业务系统不直接调用 BASE,只能调用微服务 INSTANCE。 权限认证.png 接口规范 RESTFUL:URL 的资源操作解耦,让 URL 更加符合语义,上百个接口也非常好管理,网上有很多文章讲得非常透彻,这玩意不是特别好理解,要多领悟,在项目中实践,就有矛塞盾开的感觉 服务注册发现 spring cloud eureka 服务接口改变后,再也不需要口头通知服务调用者了,因为调用者太多,你根本不知道他是谁,难免遗漏;可支持 PHP。 ?

    76061

    vivo服务端监控架构设计实践

    二、vivo服务端监控系统架构及演进之路 在介绍vivo服务端监控系统架构之前,先带大家了解一下OpenTSDB时序数据库,在了解之前说明下为什么我们会选择OpenTSDB,原因有以下几点: 1) 监控数据采集指标在某一时间点具有唯一值 2.5 vivo服务端监控老版本部署架构 1)自建机房A:部署架构以国内为例,监控工程部署在自建机房A,监听本机房的RabbitMQ消息,依赖的Redis、OpenTSDB、MySQL、Zookeeper ,借鉴行业最佳监控实践。 [图片] 七、总结 [图片] 本文主要介绍了vivo服务端监控架构的设计演进之路,是基于java技术栈做的一套实时监控系统,同时也简单列举了行业内主流的几种类型的监控系统,希望有助于大家对监控系统的认识 监控体系里面涉及到的面很广,是一个庞大复杂的体系,本文只是介绍了服务端监控里的JVM监控,系统监控以及业务监控(包含日志监控和工具类代码侵入式上报),未涉及到客户端监控和全链路监控等,如果想理解透彻,必须理论结合实践再做深入

    16730

    vivo 云服务海量数据存储架构演进实践

    二、面临挑战 2017-2018年,云服务产品核心指标着重于提升用户量。云服务在产品策略上做了重大调整,用户登录 vivo 账号后默认开启云服务数据同步开关。 为了解决海量数据的存储问题,云服务将分库分表的 4 板斧:水平分表、垂直分表、水平分库、垂直分库,全部进行了实践。 1、水平分表 荆棘之路 1:浏览器书签、便签单库单表,单表数据量已过亿级怎么办? 至此,云服务将分库分表的 4 板斧全部实践了一遍,数据该拆的拆,该分的分。 五、线上实践 从上述测试验证来看,压缩率若能达到50%,那么联系人老库占用空间从65%压缩至33%,预留60%的剩余空间是能够达成的。 但是对线上的数据我们需要保持敬畏之心,线上实践之前,需要线下先进行方案验证,同时我们还需要考虑以下问题: 1、数据压缩,解压操作是否对db服务器的性能造成影响?

    31200

    服务架构统一安全认证设计实践

    Authorization server:认证服务器,即服务提供商专门用来处理认证的服务器。 Resource server:资源服务器,即服务提供商存放用户生成的资源的服务器。 它与认证服务器,可以是同一台服务器,也可以是不同的服务器。 主要的四种授权方式: 授权码模式(authorization code)用在客户端服务端应用之间授权码。 简化模式(implicit)用在移动 app 或者 web app(这些 app 是在用户的设备上的,如在手机上调起信来进行认证授权)。 ---- ---- 欢迎加入我的知识星球,一起探讨架构,交流源码。

    6810

    保 Serverless 实践架构演进

    背景 保前端架构在业务发展中,根据业务、团队、开发等实际情况,不断进化调整。本文将具体介绍保前端的架构演进过程,以及团队最终选择使用腾讯云 Serverless 技术支撑前端架构的原因。 架构 v1 早期,团队使用经典的前后分离架构,前端开发后端开发通过接口进行合作。 合作流程如下图所示: ? 毫无疑问,前后端分离的架构有比较显著的优势: 1. 利于前端组件化后端微服务架构 前后端分离后,前端可以使用更为便捷的框架以及基于这些框架的基础UI组件,大大提升开发效率。 架构 v2 鉴于上述前后端合作模式中的痛点,团队对架构再次进行优化,原则是业务“前”移、核心下沉。在前期的各种业务支撑中,团队已经有了一些业务中台的沉淀,比如投保服务、续保服务、保单服务等。 前端开发同学业务产品沟通业务逻辑,在api市场或服务文档查询相应的服务能力,完成业务开发。同时对于团队逐步开展业务中台化、前端组件化大有助益,整个架构对于丰富多变的业务需求的响应更敏捷。 2.

    3.6K520303

    服务架构下的移动架构实践

    很高兴又与大家见面了,今天和大家分享的主题是: 《微服务架构下的移动架构实践》。 希望本次分享对大家能有帮助,也希望各位专家能够多多拍砖。 一、基于微服务的云架构是移动互联的趋势 ? 同样,移动互联网的建设也正面向基于微服务的云架构来进行设计,这势必会对移动前端技术带来新的挑战。移动架构如何适应这种变化?面向Cloud的编程,移动端应用之前有何不同,又如何开展研发工作? 二、微服务架构下的移动架构演进实现 ? 记得一个月前,我做过一次《数字化企业云平台下的移动平台建设》课堂,我们先回顾一下当时的一张PPT——《移动平台发展现状趋势:移动架构的演进》。 ? 今天重点聚焦在,微服务架构下,统一接入架构的设计实现中我的一些想法。 统一接入架构是可以避免App端服务器端直接通信的一种方式,常见的架构里通常采用API Gateway的方式,如下图: ? 所以,在我们的实践中,我们会将服务发现和注册的系统放入内网中,如下图: ?

    97640

    前端架构探索实践

    而我们使用源码编写,主要是基于以下几点思考: 稳定性要求高 页面模块多而不定 快速回滚方案 模块通信复杂 源码架构 ? 架构图 ❝架构图需要调整。 所以对于中间页的架构而言也是如此。 首先拿到基本的接口数据,通过自定义的状态管理,挂载到全局 state 对应的组件名下。容器层通过组件的配置文件,渲染对应的组件。最终呈现出完成的一个页面。 offsetTop < (screen.height || screen.availHeight || 0)); }, [comRef]); return canLoad; } 模块编写状态分发 手动下拉页面容器的橡皮筋效果冲突,而「倒是页面疯狂抖动」。所以。。。。重构。 旧版容器功能点 ❝源码页面中使用的部分 ❞ ? 重构后的使用 ❝基本没有太大改变 ❞ ? ,基于 react 应用 发布端架构模板地址:publish-project pmc publish-add 添加发布端模块 模块模板地址:publish-mod pmc init-mod 调用 def

    22820

    好雨·极客汇|微服务架构实践应用

    随着Docker技术的发展,系统的架构设计逐渐成为系统构建的关键一环,微服务架构模式也被很多企业的技术决策者所关注。 关于这些,本次沙龙将邀请国内微服务架构领域的大咖分享更多关于微服务架构实践干货。 本次沙龙开始时间是4月16日下午2点,地址在北京望京商业中心F座B208 演讲主题1:微服务架构的开发实施 议题简介:本次讲座以OneAPM内部微服务架构平台为例,从简单使用OpenStack搭建简单的微服务开发环境 演讲嘉宾:张晓光,目前在OneAPM基础架构部,主要从事Java、Scala开发,负责公司公共服务研发以及DevOps推广实践。 演讲主题3:微服务架构的云端应用 议题简介:介绍微服务架构及其优缺点,讲解常见的微服务架构模式和适用场景,并结合实践,选择合适的云平台,讲解如何部署,管理,迁移和服务伸缩,最后讲解实际运营中的问题和解决方案

    29530

    服务架构原理治理实践|青训营笔记

    服务架构介绍 架构概览 优势: 开发效率高、2. 业务独立设计、3. 自下而上、4. 故障隔离 劣势: 治理、运维难度高、2. 观测挑战、3. 安全性、4. 黑客攻击 微服务架构原理及特征 服务间通信 对于单体服务,不同模块通信只是简单的函数调用,对于微服务服务间通信意味着网络传输。 服务注册及发现 在代码层面,如何指定调用一个目标服务的地址(ip:port)? 解决思路:新增一个统一的注册中心,用于存储服务名到服务实例的映射。 流量治理 在微服务架构下,我们可以基于地区、集群、实例、请求等维度,对端到端流量的路由进行精确控制。 负载均衡 负载均衡负责分配请求在每个下游实例上的分布。 下面给出了微服务治理中的四个经典功能: 字节跳动服务治理实践 针对于微服务架构中的请求重试机制字节给出了如下实践: 重试的意义 本地函数重试基本上是没有意义的,而远程函数重试则有意义,因为其发生请求错误的原因可能不是下游程序编写出错

    3520

    信许家滔:信10亿日活场景下,后台微服务架构及存储架构实践

    作者介绍:许家滔,信技术架构部后台总监,专家工程师,多年来伴随QQ邮箱和信后台成长,历经系统从0到10亿级用户的过程。目前负责信后台工作,包括消息,资料关系链,后台基础设施等内容。 早期的QQ不同,它更像是一个邮箱。 后来逐渐完善,包括内部安全、管理等。 目前,最关注的有两个方面: 第一是,高可用。信作为国民级应用,对高可用有着极高的要求,是不可以有服务暂停的。 上面提到的这个论文是信PaxosStore的一点创新,贡献出了一些简洁的算法实现流程,大家可以很轻松的去理解和实现。 06 PaxosStore整体架构 PaxosStore整体架构,如下图。 07 信Chubby建设实践 Chubby是Google一个论文提到的系统,信技术团队延伸了这样一个逻辑,基本上跟它的接口是一样的。 09 信微服务架构框架 微服务包含了服务定义、服务发现、错误重试、监控容灾、灰度发布等一系列面向服务的高级特性的统一框架。

    4.5K434

    单体架构服务架构

    由于单体架构的缺陷日益明显,所以越来越多的公司采用微服务架构范式解决上面提到的单体架构中的问题。 不同于构建单一、庞大的应用,微服务架构将应用拆分为一套小且互相关联的服务。 【微服务架构】 1. 什么是微服务架构 简而言之,微服务架构风格的开发方法,是以开发一组小型服务的方式来开发一个独立的应用系统的。 ,如订单管理、用户管理等; - 微服务之间通过一些轻量的通信机制进行通信,如REST API进行调用; - 可以使用不同的语言存储技术; - 全自动的部署机制 在单体架构中只需要保证一个应用的正常运行;而在微服务中,需要保证几十甚至几百个服务的正常运行协作,带来了巨大的挑战; - 分布式固有的复杂性。使用微服务构建的是分布式系统。 微服务架构模式可以用来构建复杂应用,当然,这种架构模型也有自己的缺点和挑战。

    1.1K30

    相关产品

    • Mesh 微服务平台

      Mesh 微服务平台

      Mesh 微服务平台提供了下一代微服务架构-服务网格的解决方案。Mesh 微服务平台支持跨编程语言、不同部署方式的应用生命周期管理、精细化的服务治理、立体化监控能力,帮助大型企业客户解决编程语言不统一、部署方式不统一等架构转型的困难;支持强大的服务流量路由能力,帮助用户实现灰度发布、故障注入等业务场景。

    相关资讯

    热门标签

    活动推荐

    扫码关注腾讯云开发者

    领取腾讯云代金券