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