微服务思想

原文地址

微服务系统如何拆分?

  • 先粗后细,不要过细,切忌一个接口一个服务

  • 横向拆分,而非纵向,我们尽量不要超过三层调用

  • 单向调用,严禁循环调用

  • 禁止接口类型透传,在不同的层之间不要共享同一个数据定义,避免一处修改,影响其它

  • 没有依赖关系的串行调用改为并行,可以通过 core/mr 包降低响应延迟而不增加系统负载

    图片

如何保障高并发高可用?

  • 良好的数据边界

    数据边界是微服务拆分的核心,不同的服务之间不要显示共享数据,而应该通过 rpc 共享。

  • 高效的缓存管理

    服务能否支撑高并发,缓存很关键。缓存机制不光要设计好,还需要通过工具尽可能让业务开发人员避免出错,因为缓存代码的编写有相当的难度,goctl 很好的生成了自动管理缓存的代码。

  • 优雅的熔断降载保护

    微服务系统一般都是由大量服务共同组合而成的,服务多了自然会有某个服务出现故障的风险,我们不能让某个服务的故障导致整个系统不可用,这就是服务雪崩,要避免雪崩,我们就需要有效隔离有故障的服务,从而降级可用。熔断和降载是防止服务雪崩的最有效手段之一。

  • 弹性伸缩能力

    对于高并发的系统来说,突发流量洪峰的情况下,系统需要能够及时水平扩容,go-zero 的自适应降载可以很好的配合 kubernetes 集群的自动水平伸缩能力。

  • 清晰的资源使用定义

    要想让系统保持稳定,我们一定要对资源使用做清晰的定义,比如我们到底在什么时候考虑扩充资源,是资源占用率达到了50%还是70%,必须对系统资源的使用状况有足够清晰的定义。

  • 高效的监控报警

    我在团队内部一直强调:没有度量就没有优化。我们必须对系统有高效的监控和及时的报警机制。这样才能让我们对整个系统的运行状态有足够的了解。

大型微服务项目从何下手?

图片

微服务系统大体上看起来如上图,但是我们并不是一定要业务一开始就上微服务,我们看看一个典型的微服务系统是怎么进化而来的,下面粗略的讲解一下大型微服务系统的进化过程。

  • 从单体服务开始

    项目刚开始,我们不要一味的追求技术的先进性,因为大部分项目是走不到高并发的那一天的,我们需要的是第一时间满足业务。

  • 业务优先,技术支撑

    我在团队里讲:架构是从业务中来,到业务中去。任何脱离了业务的技术都是自嗨,我们需要把满足业务需要作为第一优先级,技术需要支撑业务现在和可预期发展的需要即可。当然,有满足自身业务的现成的框架和最佳实践那是最好了,但不要让技术栈过于复杂,避免重心从业务转移到技术本身来。

  • 服务指标监控

    随着业务的发展,我们可能需要对技术做一定的升级和改造了,但是我们一直强调:没有度量就没有优化。所以我们需要及时加上对整个服务的关键指标的监控,从而让我们在了解系统的前提下进行必要的改造。

  • 数据拆分+缓存管理

    当业务发展到一定程度之后,基于监控,我们发现服务必须要做拆分了。那么我们第一步要做的是先把数据拆分清楚,数据拆分后,我们就可以加上对应的缓存管理,从而保障数据层面的稳定性。

  • 服务拆分

    相对于数据拆分,服务的拆分相对是比较容易的,基于拆分好的数据,对应出上层的服务,因为服务是无状态的,所以这个拆分就比较容易。

  • 支撑系统建设

    随着业务的发展,日常的系统维护工作就显得比较繁琐和容易出错了。此时,我们需要建设支撑系统,如何部署新服务,如何更新老服务,是不是要上 kubernetes,等等。

  • 自动化+工程建设

    当业务发展到一定程度,工程效率就是一个很大的问题了。goctl 就是为了解决自动化和工程效率问题而生,其中内置的 api, rpc, model, Dockerfile, k8s部署文件等的自动生成节省了我们大量时间,也避免了业务开发中的错误。

本作品采用《CC 协议》,转载必须注明作者和本文链接
秦晓武
讨论数量: 0
(= ̄ω ̄=)··· 暂无内容!

讨论应以学习和精进为目的。请勿发布不友善或者负能量的内容,与人为善,比聪明更重要!