微服务 微服务专题

24 | 微服务架构该如何落地?

  |   0 评论   |   261 浏览

专栏前面的文章我给你讲解了微服务架构的各个组成部分,以及实践过程中可能遇到的问题和对应的解决方案,到这里你应该对微服务架构有了一个完整的认识。那么在实际项目中,如何让一个团队把我们所学的微服务架构落地呢?

今天我就结合自己的经验,定位在中小规模团队,谈谈微服务架构到底该如何落地。

23 | 如何搭建微服务治理平台?

  |   0 评论   |   372 浏览

我给你讲过单体应用改造为微服务架构后,服务调用从本地调用变成了远程方法调用后,面临的各种不确定因素变多了,一方面你需要能够监控各个服务的实时运行状态、服务调用的链路和拓扑图;另一方面你需要在出现故障时,能够快速定位故障的原因并可以通过诸如降级、限流、切流量、扩容等手段快速干预止损。这个时候就需要我今天要讲的微服务治理平台了。

那么微服务治理平台都具备哪些功能呢,具体该如何搭建一套微服务治理平台呢?

22 | 如何管理服务配置?

  |   0 评论   |   235 浏览

今天我给你讲解了微服务架构下如何使用配置中心对服务的配置进行管理,以及实际业务中可能用到的场景,最后给出了一些开源配置中心的解决方案。关于业务中是否需要用到配置中心,以及选择哪种配置中心,要根据实际情况而定,如果业务比较简单,配置比较少并且不经常变更的话,采用本地配置是最简单的方案,这样的话不需要额外引入配置中心组件;相反,如果业务比较复杂,配置多而且有动态修改配置的需求的话,强烈建议引入配置中心来进行管理,而且最好做到配置变更实时推送给客户端,并且可以通过统一的管理界面来管理配置,这样的话能极大地降低运维的复杂度,减少人为介入,从而提高效率。

20 | 服务端出现故障时该如何应对?

  |   0 评论   |   217 浏览

今天我们探讨了微服务系统可能出现的三种故障:集群故障、单IDC故障、单机故障,并且针对这三种故障我给出了分别的解决方案,包括降级、限流、流量切换以及自动重启。

在遇到实际的故障时,往往多个手段是并用的,比如在出现单IDC故障,首先要快速切换流量到正常的IDC,但此时可能正常IDC并不足以支撑两个IDC的流量,所以这个时候首先要降级部分功能,保证正常的IDC顺利支撑切换过来的流量。

19 | 如何使用服务路由?

  |   0 评论   |   208 浏览

那么什么是服务路由呢?我的理解是服务路由就是服务消费者在发起服务调用时,必须根据特定的规则来选择服务节点,从而满足某些特定的需求

那么服务路由都有哪些应用场景?具体都有哪些规则呢?

18 | 如何使用负载均衡算法?

  |   0 评论   |   686 浏览

为什么要引入负载均衡算法呢?主要有两个原因:一个是要考虑调用的均匀性,也就是要让每个节点都接收到调用,发挥所有节点的作用;另一个是要考虑调用的性能,也就是哪个节点响应最快,优先调用哪个节点。

不同的负载均衡算法在这两个方面的考虑不同,下面我就来能给介绍常见的负载均衡算法及其应用场景。

17 | 如何识别服务节点是否存活?

  |   0 评论   |   234 浏览

今天我给你讲解了动态注册中心在实际线上业务运行时,如果遇到网络不可靠等因素,可能会带来的两个问题,一个是服务消费者同时并发访问注册中心获取最新服务信息导致注册中心带宽被打满;另一个是服务提供者节点被大量摘除导致服务消费者没有足够的节点可以调用。

16 | 如何搭建一套适合你的服务追踪系统?

  |   0 评论   |   530 浏览

业界比较有名的服务追踪系统实现有阿里的鹰眼、Twitter开源的OpenZipkin,还有Naver开源的Pinpoint,它们都是受Google发布的Dapper论文启发而实现的。其中阿里的鹰眼解决方案没有开源,而且由于阿里需要处理数据量比较大,所以鹰眼的定位相对定制化,不一定适合中小规模的业务团队,感兴趣的同学可以点击本期文章末尾“拓展阅读”进行学习。

14 | 开源RPC框架如何选型?

  |   0 评论   |   1,336 浏览

专栏第6期我给你讲解了RPC远程调用的原理,简单回顾一下一个完整的RPC框架主要有三部分组成:通信框架、通信协议、序列化和反序列化格式。根据我的经验,想要开发一个完整的RPC框架,并且应用到线上生产环境,至少需要投入三个人力半年以上的时间。这对于大部分中小团队来说,人力成本和时间成本都是不可接受的,所以我建议还是选择开源的RPC框架比较合适。

13 | 开源服务注册中心如何选型?

  |   0 评论   |   963 浏览

上一期我给你讲了服务注册中心的落地实践,以及在实际应用中可能会遇到的问题和对应的解决方案。关于注册中心,如果你的团队有足够的人才和技术储备,可以选择自己研发注册中心。但对于大多数中小规模团队来说,我的建议是最好使用业界开源的、应用比较成熟的注册中心解决方案,把精力投入到业务架构的改造中,不要自己造轮子。