微服务
文章平均质量分 91
微服务
_Rye_
左手代码右手诗
一行代码一行诗
展开
-
微博技术解密(下)| 微博存储的那些事儿
今天讲解了微博业务中使用范围最广的三个存储组件:一个是 MySQL,主要用作持久化存储数据,由于微博数据访问量大,所以进行了数据库端口的拆分来降低单个数据库端口的请求压力,并且进行了读写分离和异地灾备,采用了 Master-Slave-Backup 的架构;一个是 Memcached,主要用作数据库前的缓存,减少对数据库访问的穿透并提高访问性能,采用了 L1-Master-Slave 的架构;原创 2023-12-11 18:48:17 · 1057 阅读 · 0 评论 -
微博技术解密(上) | 微博信息流是如何实现的?
今天讲解了微博 Feed 的存储架构以及业务架构的选型,你可以看到最终方案都是结合微博的业务场景以及当时存储的成熟度做出的选择。微博诞生于 2009 年,并在 2010 年进行了平台化改造,确定了现在这一套存储和业务架构。当时的存储成熟度决定了 MySQL + Memcached 的组合是最优解,并没有使用 Redis、HBase 等后来更为先进的数据库;同时由于微博 Feed 的业务特点,选择了拉模式的业务架构,并针对关注人数上千的场景进行了拉取方式的优化,也被实践证明是行之有效的手段。原创 2023-12-11 17:37:36 · 1056 阅读 · 0 评论 -
36 | 微博Service Mesh实践之路(下)
今天从 Motan-go Agent 和统一服务治理中心的具体实现这两个方面,讲解了 Weibo Mesh 的技术细节,可以看到很多都是微博基于自身业务特点定制化的解决方案。对于大部分中小团队来说,除非从一开始就采用了云原生应用的部署方式,否则 Istio 等开源方案并不能直接拿来就用,都需要从自身的业务特征和既有技术体系出发,选择一条适合自己的 Service Mesh 实践之路。原创 2023-12-11 15:14:47 · 931 阅读 · 0 评论 -
35 | 微博Service Mesh实践之路(上)
今天讲解了微博是如何一步步走向 Service Mesh 之路的,从这个过程可以看出微博的 Weibo Mesh 并不是一开始就是设计成这样的,它是随着业务的发展,对跨语言服务调用的需求日趋强烈,才开始探索如何使得原有仅支持 Java 语言的服务化框架 Motan 支持多语言,在这个过程中又不断尝试了各种解决方案之后,才笃定了走 Agent 代理这条路,并实际应用到线上。原创 2023-12-11 14:33:37 · 823 阅读 · 0 评论 -
34 | Istio:Service Mesh的代表产品
今天详细讲解了 Istio 的架构及其基本组件 Proxy、Pilot、Mixer 以及 Citadel 的工作原理,从 Istio 的设计和实现原理可以看出,它是采用模块化设计,并且各个模块之间高度解耦,Proxy 专注于负责服务之间的通信,Pilot 专注于流量控制,Mixer 专注于策略控制以及监控日志功能,而 Citadel 专注于安全。原创 2023-12-11 14:22:06 · 934 阅读 · 0 评论 -
33 | 下一代微服务架构Service Mesh
Service Mesh 的概念最早是由 Buoyant 公司的 CEO William Morgan 在一篇文章里提出,他给出的服务网格的定义是:专栏里就不解释教条的定义了,感兴趣的话可以点击链接阅读原文,这里来谈谈对 Service Mesh 的理解。我认为是 Service Mesh 是一种新型的用于处理服务与服务之间通信的技术,尤其适用以云原生应用形式部署的服务,能够保证服务与服务之间调用的可靠性。原创 2023-12-11 11:25:44 · 775 阅读 · 0 评论 -
32 | 微服务混合云部署实践
今天讲解了微服务混合云部署必须解决的三个问题:跨云服务的负载均衡、跨云服务的数据同步、跨云服务的容器运维,以及微博在微服务混合云部署时的实践方案,可以说正是由于采用了混合云部署,才解决了微博在面对频繁爆发的热点事件带来突发流量时,内部资源冗余度不足的问题。虽然云原生应用现在越来越流行,但对于大部分企业来说,完全脱离内部私有云并不现实,因为云也不是完全可靠的,一旦云厂商出现问题,如果没有内部私有云部署的话,那么服务将完全不可用。如果你的服务对高可用性要求很高,那么混合云的方案更加适合你。原创 2023-12-11 10:08:52 · 927 阅读 · 0 评论 -
31 | 微服务多机房部署实践
今天讲解了微服务多机房部署时要面临的三个问题,一是多机房访问时如何保证负载均衡,二是多机房之间的数据如何保证同步,三是多机房之间的数据如何保证一致性,并给出了微博在多机房部署微服务时所采取的解决方案,对于大部分中小业务团队应该都有借鉴意义。可以说多机房部署是非常有必要的,尤其是对可用性要求很高的业务来说,通过多机房部署能够实现异地多活,尤其可以避免因为施工把光缆挖断导致整个服务不可用的情况发生,也是业务上云实现混合云部署的前提。下一期再来聊聊微服务混合云部署的实践,可以对多机房部署的重要性有更深的认识。原创 2023-12-11 09:46:40 · 928 阅读 · 0 评论 -
30 | 如何做好微服务容量规划?
今天从两个方面具体讲解了微服务如何做好容量规划的问题,即做好容量评估和调度决策。容量评估方面,首先要通过压测获取集群的最大容量,并实时采集服务调用的数据以获取集群的实时运行负荷,这样就可以获取集群的实时水位线。而调度决策方面,主要是通过水位线与致命线和安全线对比来决定什么时候该扩缩容。而扩缩容的数量也是有讲究的,扩容的机器数一般按照集群机器数量的比例来,而缩容一般采取逐步缩容的方式以免缩容太快导致反复扩容。原创 2023-12-11 09:19:03 · 1147 阅读 · 0 评论 -
29 | 微服务如何实现DevOps?
在介绍 DevOps 之前,先来回顾一下传统的业务上线流程:开发人员开发完业务代码后,把自测通过的代码打包交给测试人员,然后测试人员把代码部署在测试环境中进行测试,如果测试不通过,就反馈 bug 给开发人员进行修复;如果通过,开发就把测试通过的代码交给运维人员打包,然后运维人员再发布到线上环境中去。可见在传统的开发模式下,开发人员、测试人员和运维人员的职责划分十分明确,他们往往分属于不同的职能部门,一次业务上线流程需要三者之间进行多次沟通,整个周期基本上是以天为单位。原创 2023-12-11 09:17:13 · 1019 阅读 · 0 评论 -
28 | 微服务容器化运维:微博容器运维平台DCP
今天讲解了微博容器运维平台 DCP 的架构,主要包括基础设施层、主机层、调度层以及编排层,并详细介绍了每一层的功能实现,以及各自承担的不同职能。下面这张图是一次完整扩容流程,包括了资源评估、配额评估、初始化、容器调度、部署服务、服务依赖、服务发现以及自动扩缩容等,DCP 正是通过把这些过程串联起来,实现容器运维的。原创 2023-12-10 17:42:20 · 1001 阅读 · 0 评论 -
27 | 微服务容器化运维:容器调度和服务编排
今天讲解了容器运维平台的另外两个关键组成:容器调度和服务编排,并给出了常用的解决方案。你的业务团队在选择解决方案时,要根据自己的需要选择合适的方案,而不是理论上最好的。比如 Kubernetes 解决方案在容器调度、服务编排方面都有成熟的组件,并且经过大业务量的实际验证。但是要考虑到 Kubernetes 本身的复杂性以及概念理解的门槛,对于大部分中小业务团队来说,在生产环境上使用 Kubernetes 都会显得大材小用,并且还需要部署并运维 Kubernetes 周边的一些基础设施,比如 etcd 等。原创 2023-12-09 23:17:35 · 1053 阅读 · 2 评论 -
26 | 微服务容器化运维:镜像仓库和资源调度
今天讲解了容器运维平台的两个关键组成,镜像仓库和资源调度。镜像仓库帮我们解决的是 Docker 镜像如何存储和访问的问题,在业务规模较大时,各个业务团队都需要搭建自己的私有镜像仓库。类似 Harbor 这种开源解决方案能很好地解决权限控制、镜像同步等基本问题,关于高可用性的要求以及上云支持等业务场景,可以参考我给出的解决方案,它是经过微博实际线上业务验证过的。原创 2023-12-09 21:18:31 · 926 阅读 · 0 评论 -
25 | 微服务为什么要容器化?
Docker 是容器技术的一种,事实上已经成为业界公认的容器标准,要理解 Docker 的工作原理首先得知道什么是容器。容器翻译自英文的 Container 一词,而 Container 又可以翻译成集装箱。我们都知道,集装箱的作用就是,在港口把货物用集装箱封装起来,然后经过货轮从海上运输到另一个港口,再在港口卸载后通过大货车运送到目的地。这样的话,货物在世界的任何地方流转时,都是在集装箱里封装好的,不需要根据是在货轮上还是大货车上而对货物进行重新装配。原创 2023-12-09 19:03:57 · 889 阅读 · 0 评论 -
24 | 微服务架构该如何落地?
今天讲解了微服务架构如何在业务中进行落地,总结来讲就是,首先你必须组建一支合适的技术团队,这其中不仅要包含资深的架构师,还需要包含业务的开发者。在选择业务进行微服务架构改造时,不能追大求全,正确的做法应当是先以一个适当规模的业务进行微服务改造,走完整个微服务架构落地的过程,从而找出问题,不断打磨到成熟可用的状态,再推广到更多更重要的业务当中。在改造的过程中,要做好技术取舍,以团队人员的实际情况以及业务的实际需求为准绳,切忌追新立异,避免给业务引入不可控因素,留下“架构债”。原创 2023-12-09 17:54:10 · 775 阅读 · 0 评论 -
23 | 如何搭建微服务治理平台?
可以说一个微服务框架是否成熟,除了要看它是否具备服务治理能力,还要看是否有强大的微服务治理平台。因为微服务治理平台能够将多个系统整合在一起,无论是对开发还是运维来说,都能起到事半功倍的作用,这也是当前大部分开源微服务框架所欠缺的部分,所以对于大部分团队来说,都需要自己搭建微服务治理平台。不过好在微服务治理平台本身的架构并不复杂,你可以根据自己的实际需要,来决定微服务治理平台具备哪些功能。原创 2023-12-09 10:46:30 · 1030 阅读 · 0 评论 -
22 | 如何管理服务配置?
今天讲解了微服务架构下如何使用配置中心对服务的配置进行管理,以及实际业务中可能用到的场景,最后给出了一些开源配置中心的解决方案。关于业务中是否需要用到配置中心,以及选择哪种配置中心,要根据实际情况而定,如果业务比较简单,配置比较少并且不经常变更的话,采用本地配置是最简单的方案,这样的话不需要额外引入配置中心组件;原创 2023-12-09 10:00:27 · 901 阅读 · 0 评论 -
21 | 服务调用失败时有哪些处理手段?
今天讲解了微服务架构下服务调用失败的几种常见手段:超时、重试、双发以及熔断,实际使用时,具体选择哪种手段要根据具体业务情况来决定。根据经验,大部分的服务调用都需要设置超时时间以及重试次数,当然对于非幂等的也就是同一个服务调用重复多次返回结果不一样的来说,不可以重试,比如大部分上行请求都是非幂等的。至于双发,它是在重试基础上进行一定程度的优化,减少了超时等待的时间,对于长尾请求的场景十分有效。采用双发策略后,服务调用的 P999 能大幅减少,经过我的实践证明是提高服务调用成功率非常有效的手段。原创 2023-12-08 23:25:21 · 1371 阅读 · 0 评论 -
20 | 服务端出现故障时该如何应对?
今天我们探讨了微服务系统可能出现的三种故障:集群故障、单 IDC 故障、单机故障,并且针对这三种故障我给出了分别的解决方案,包括降级、限流、流量切换以及自动重启。在遇到实际的故障时,往往多个手段是并用的,比如在出现单 IDC 故障,首先要快速切换流量到正常的 IDC,但此时可能正常 IDC 并不足以支撑两个 IDC 的流量,所以这个时候首先要降级部分功能,保证正常的 IDC 顺利支撑切换过来的流量。而且要尽量让故障处理自动化,这样可以大大减少故障影响的时间。原创 2023-12-08 22:37:37 · 836 阅读 · 0 评论 -
19 | 如何使用服务路由?
今天讲解了服务路由的作用,简单来讲就是为了实现某些调用的特殊需求,比如分组调用、灰度发布、流量切换、读写分离等。在业务规模比较小的时候,可能所有的服务节点都部署在一起,也就不需要服务路由。但随着业务规模的扩大、服务节点增多,尤其是涉及多数据中心部署的情况,把服务节点按照数据中心进行分组,或者按照业务的核心程度进行分组,对提高服务的可用性是十分有用的。原创 2023-12-08 22:21:35 · 806 阅读 · 0 评论 -
18 | 如何使用负载均衡算法?
今天讲解了最常用的五种客户端负载均衡算法的原理以及适用场景,在业务实践的过程汇总,究竟采用哪种,需要根据实际情况来决定,并不是算法越复杂越好。比如在一种简单的业务场景下,有 10 个服务节点,并且配置基本相同,位于同一个数据中心,此时客户端选择随机算法或者轮询算法既简单又高效,并没有必要选择加权轮询算法或者最少活跃连接算法。原创 2023-12-08 21:51:08 · 815 阅读 · 0 评论 -
17 | 如何识别服务节点是否存活?
今天讲解了动态注册中心在实际线上业务运行时,如果遇到网络不可靠等因素,可能会带来的两个问题,一个是服务消费者同时并发访问注册中心获取最新服务信息导致注册中心带宽被打满;另一个是服务提供者节点被大量摘除导致服务消费者没有足够的节点可以调用。这两个问题都是在业务实践过程中遇到过的,给出的两个解决方案:心跳开关保护机制和服务节点摘除保护机制都是在实践中应用过的,并且被证明是行之有效的。原创 2023-12-08 21:25:23 · 831 阅读 · 0 评论 -
16 | 如何搭建一套适合你的服务追踪系统?
今天讲解了两个开源服务追踪系统 OpenZipkin 和 Pinpoint 的具体实现,并从埋点探针支持平台广泛性、系统集成难易程度、调用链路数据精确度三个方面对它们进行了对比。从选型的角度来讲,如果你的业务采用的是 Java 语言,那么采用 Pinpoint 是个不错的选择,因为它不需要业务改动一行代码就可以实现 trace 信息的收集。除此之外,Pinpoint 不仅能看到服务与服务之间的链路调用,还能看到服务内部与资源层的链路调用,功能更为强大,如果你有这方面的需求,Pinpoint 正好能满足。原创 2023-12-08 20:15:00 · 876 阅读 · 0 评论 -
15 | 如何搭建一个可靠的监控系统?
以上几种监控系统实现方式,所采用的技术均为开源的,其中:ELK 的技术栈比较成熟,应用范围也比较广,除了可用作监控系统外,还可以用作日志查询和分析。Graphite 是基于时间序列数据库存储的监控系统,并且提供了功能强大的各种聚合函数比如 sum、average、top5 等可用于监控分析,而且对外提供了 API 也可以接入其他图形化监控系统如 Grafana。TICK 的核心在于其时间序列数据库 InfluxDB 的存储功能强大,且支持类似 SQL 语言的复杂数据处理操作。原创 2023-12-08 19:43:58 · 1117 阅读 · 0 评论 -
14 | 开源RPC框架如何选型?
以上就是对几种使用最广泛的开源 RPC 框架的选型建议,也是基于它们目前现状所作出的判断,从长远来看,支持多语言是 RPC 框架未来的发展趋势。正是基于此判断,各个 RPC 框架都提供了 Sidecar 组件来支持多语言平台之间的 RPC 调用。原创 2023-12-08 19:31:52 · 997 阅读 · 0 评论 -
13 | 开源服务注册中心如何选型?
总的来说,在选择开源注册中心解决方案的时候,要看业务的具体场景。如果你的业务体系都采用 Java 语言的话,Netflix 开源的 Eureka 是一个不错的选择,并且它作为服务注册与发现解决方案,能够最大程度的保证可用性,即使出现了网络问题导致不同节点间数据不一致,你仍然能够访问 Eureka 获取数据。如果你的业务体系语言比较复杂,Eureka 也提供了 Sidecar 的解决方案;原创 2023-12-08 18:38:41 · 868 阅读 · 0 评论 -
12 | 如何将注册中心落地?
今天讲解了在注册中心实际使用过程中,服务注册、服务反注册、服务订阅和服务变更的实现方式,并列举了几个在服务注册与发现的过程中遇到的典型问题。而针对这些异常情况,都给出了对应的解决方案,这些方案都是经过实际业务验证的,对于大部分中小团队在应用场景面临的问题,应该足以应对。原创 2023-12-08 17:51:25 · 897 阅读 · 0 评论 -
11 | 服务发布和引用的实践
今天介绍了 XML 配置方式的服务发布和引用的具体流程,简单来说就是服务提供者定义好接口,并且在服务发布配置文件中配置要发布的接口名,在进程启动时加载服务发布配置文件就可以对外提供服务了。而服务消费者通过在服务引用配置文件中定义相同的接口名,并且在服务引用配置文件中配置要引用的接口名,在进程启动时加载服务引用配置文件就可以引用服务了。在业务具体实践过程中可能会遇到引用服务的服务消费者众多,对业务的敏感度参差不齐的问题,所以在服务发布的时候,最好预定义好接口的各种配置。原创 2023-12-08 16:51:04 · 839 阅读 · 0 评论 -
10 | Dubbo框架里的微服务组件
今天讲述了 Dubbo 服务化框架每个基本组件的实现方式,以及一次 Dubbo 调用的流程。对于学习微服务架构来说,最好的方式是去实际搭建一个微服务的框架,甚至去从代码入手做一些二次开发。可以按照 Dubbo 的官方文档去安装并搭建一个服务化框架。如果想深入了解它的实现的话,可以下载源码来阅读。原创 2023-12-08 15:55:06 · 862 阅读 · 0 评论 -
09 | 微服务治理的手段有哪些?
上面讲的服务治理的手段是最常用的手段,它们从不同角度来确保服务调用的成功率。节点管理是从服务节点健康状态角度来考虑,负载均衡和服务路由是从服务节点访问优先级角度来考虑,而服务容错是从调用的健康状态角度来考虑,可谓是殊途同归。在实际的微服务架构实践中,上面这些服务治理手段一般都会在服务框架中默认集成了,比如阿里开源的服务框架 Dubbo、微博开源的服务框架 Motan 等,不需要业务代码去实现。如果想自己实现服务治理的手段,可以参考这些开源服务框架的实现。原创 2023-12-08 11:47:45 · 806 阅读 · 0 评论 -
08 | 如何追踪微服务调用?
今天讲解了服务追踪的基本原理以及实现方式,可以说服务追踪是分布式系统中必不可少的功能,它能够帮助我们查询一次用户请求在系统中的具体执行路径,以及每一条路径的上下游的详细情况,对于追查问题十分有用。实现一个服务追踪系统,涉及数据采集、数据处理和数据展示这三个流程,有多种实现方式,具体采用哪一种要根据自己的业务情况来选择。关于服务追踪系统的选型在专栏后面会详细展开介绍,这里只需要了解它的基本工作原理就可以了。原创 2023-12-08 09:35:39 · 1115 阅读 · 0 评论 -
07 | 如何监控微服务调用?
服务监控在微服务改造过程中的重要性不言而喻,没有强大的监控能力,改造成微服务架构后,就无法掌控各个不同服务的情况,在遇到调用失败时,如果不能快速发现系统的问题,对于业务来说就是一场灾难。搭建一个服务监控系统,涉及数据采集、数据传输、数据处理、数据展示等多个环节,每个环节都需要根据自己的业务特点选择合适的解决方案,关于监控技术方案的选型会在专栏后面进行详解。原创 2023-12-07 23:57:12 · 871 阅读 · 0 评论 -
06 | 如何实现RPC远程服务调用?
通信框架。它主要解决客户端和服务端如何建立连接、管理连接以及服务端如何处理请求的问题。通信协议。它主要解决客户端和服务端采用哪种数据传输协议的问题。序列化和反序列化。它主要解决客户端和服务端采用哪种数据编解码的问题。这三个部分就组成了一个完整的 RPC 调用框架,通信框架提供了基础的通信能力,通信协议描述了通信契约,而序列化和反序列化则用于数据的编 / 解码。原创 2023-12-07 21:58:30 · 1458 阅读 · 0 评论 -
05 | 如何注册和发现服务?
注册中心可以说是实现服务化的关键,因为服务化之后,服务提供者和服务消费者不在同一个进程中运行,实现了解耦,这就需要一个纽带去连接服务提供者和服务消费者,而注册中心就正好承担了这一角色。此外,服务提供者可以任意伸缩即增加节点或者减少节点,通过服务健康状态检测,注册中心可以保持最新的服务节点信息,并将变化通知给订阅服务的服务消费者。原创 2023-12-07 20:44:29 · 929 阅读 · 0 评论 -
04 | 如何发布和引用服务?
今天介绍了服务描述最常见的三种方式:RESTful API、XML 配置以及 IDL 文件。具体采用哪种服务描述方式是根据实际情况决定的,通常情况下,如果只是企业内部之间的服务调用,并且都是 Java 语言的话,选择 XML 配置方式是最简单的。如果企业内部存在多个服务,并且服务采用的是不同语言平台,建议使用 IDL 文件方式进行描述服务。如果还存在对外开放服务调用的情形的话,使用 RESTful API 方式则更加通用。原创 2023-12-07 19:31:01 · 979 阅读 · 0 评论 -
03 | 初探微服务架构
通过前面的讲解,相信已经对微服务架构有了基本的认识,对微服务架构的基本组件也有了初步了解。这几个基本组件共同组成了微服务架构,在生产环境下缺一不可,所以在引入微服务架构之前,你的团队必须掌握这些基本组件的原理并具备相应的开发能力。实现方式上,可以引入开源方案;如果有充足的资深技术人员,也可以选择自行研发微服务架构的每个组件。但对于大部分中小团队来说,我认为采用开源实现方案是一个更明智的选择,一方面你可以节省相关技术人员的投入从而更专注于业务,另一方面也可以少走弯路少踩坑。不管是采用开源方案还是自行研发,原创 2023-12-07 17:00:36 · 845 阅读 · 0 评论 -
02 | 从单体应用走向服务化
无论是纵向拆分还是横向拆分,都是将单体应用庞杂的功能进行拆分,抽离成单独的服务部署。但并不是说功能拆分的越细越好,过度的拆分反而会让服务数量膨胀变得难以管理,因此找到符合自己业务现状和团队人员技术水平的拆分粒度才是可取的。我建议的标准是按照每个开发人员负责不超过 3 个大的服务为标准,毕竟每个人的精力是有限的,所以在拆分微服务时,可以按照开发人员的总人数来决定。原创 2023-12-07 14:27:56 · 894 阅读 · 0 评论 -
01 | 到底什么是微服务?
这里就不谈一些官方的、教条主义的概念了。在我看来,用通俗的话来讲,服务化就是把传统的单机应用中通过 JAR 包依赖产生的本地方法调用,改造成通过 RPC 接口产生的远程方法调用。一般在编写业务代码时,对于一些通用的业务逻辑,会尽力把它抽象并独立成为专门的模块,因为这对于代码复用和业务理解都大有裨益。在过去的项目经历里,对此深有体会。以微博系统为例,微博既包含了内容模块,也包含了消息模块和用户模块等。其中消息模块依赖内容模块,消息模块和内容模块又都依赖用户模块。原创 2023-12-07 00:34:25 · 874 阅读 · 0 评论 -
开篇词 | 微服务,从放弃到入门
从经验来看,实践微服务的过程本身也是一个升级打怪的过程,这中间会遇到基本上所有后端架构的问题。当时为了解决这些问题,做了很细致的技术调研,最后选定了服务化的解决方案,对原有的单体应用架构进行改造,把功能相对独立的模块拆分出去,部署为微服务,分别交给专门的更小的团队来维护。即使你现在还没有用到微服务,但通过学习,希望一样能够掌握微服务架构的思维的精髓,提升解决复杂问题的能力。第二部分,会结合在实际业务中的经验,讲述微服务架构改造过程中可能会遇到的问题和对应的解决方案,以及搭建微服务架构时,如何做技术选型。原创 2023-12-06 23:46:08 · 348 阅读 · 0 评论