微服务如何落地

522 阅读4分钟

为什么要微服务化?

在决定推动项技术升级之前,我习惯先问问自己为什么要做,譬如收益和付出是什么,如果没有想清楚,宁愿不做。

微服务也不例外,我们不能盲目跟风,一定要结合自己的实际,慎重地决定是否需要微服务化。

网上关于微服务好处的介绍有很多,这里我想特别强调的是,从“人”的角度讲,微服务带来的优势和挑战。

微服务架构下,每个服务的复杂度大幅下降,从而维护成本也大幅降低。对于团队来说,新人也可以更快地上手项目,贡献代码。交接项目也变得更加容易。

单一服务架构下,随着时间的推移,项目的复杂度必然越来越高,相关人员也会越来越多,从而代码的合并频率会逐渐下降,权限越来越难以分配,需要越来越重的测试,部署也越来越复杂,频率越来越低。

然而微服务也会带来很多问题,例如如果设计不合理,整体的复杂度会提高。写代码的时候需要考虑调用失败的情况,需要考虑分布式的事务(当然很多时候是设计不合理导致的),从而对人提出了更高的要求。

总之,微服务带来了很多优势,同时也带来了很多挑战,我们需要认真的审视自己,这些优势对当下的我们是否是优势,这些挑战对当下的我们是否能hold住。

关键问题一:如何划分微服务

这里有几点心得:

  • 区分边界服务和内部服务。所谓边界服务就是会接受公网流量的服务,比如处理 HTTP 请求的服务,反之就是内部服务。边界服务和内部服务在安全方面的考虑是不一样的(例如边界服务需要做针对User的鉴权等等)
  • 区分基础和业务服务。业务服务追求变化,feature,基础服务追求稳定,性能。
  • 微服务的调用,一定要考虑调用会失败。
  • 没有把握的做到合理拆分的时候可以选择先不拆,等到发现瓶颈了自然就知道怎么拆了

关键问题二:微服务和 DevOps

微服务除了是个技术活,更是个管理活。我们得有和微服务相融的团队组织方式和工作流程。

  • 要有架构组,架构组要负责微服务的基础设施的建设,例如 CI/CD系统, Kubernetes 集群,Service Mesh 集群,监控报警系统,日志手机系统,基础的工具和库的构建和维护。
  • 每个微服务要有固定的团队负责(实践中,可以是对微服务分组,每组微服务对应一组特定的人)。每个团队都要有人负责 DevOps 全套流程,包括 CI/CD 的使用,Kubernetes yaml 的维护,组内权限的分配,监控报警的响应等等。每个团队都对自己负责的微服务全权负责(从开发,到上线,到维护,到调优)。

在扇贝,我们就对微服务根据其业务特性,技术特性做了一些分组,每组微服务对应 2-3 人的 DevOps 团队,每个团队实现自己的 DevOps 流程(架构团队提供流程模板)。

每个团队使用 GitLab CI 来实现 CI/CD:提交PR开始跑测试,测试通过进入代码Review,Review通过合并进主分支,开始自动构建 Docker Image,然后依次部署到 集成测试,预发布,生产环境。

每个团队都可以在监控报警系统中看到自己负责的项目的运行数据,甚至自定义监控数据和报警指标,当数据发生异常,自己会收到报警,然后去处理。

不同的微服务团队相互独立,通过gRPC 和 Celery 实现数据交换。

最后给大家推荐下微服务全家桶,作为一个Check List,上微服务的同学可以勾一勾

  • [ ] DevOps(CI/CD)
  • [ ] Container(Docker)
  • [ ] Kubernetes
  • [ ] Service Mesh

欢迎关注我们的知乎专栏