微服务如何落地

为何要微服务化？

在决定推进项技术升级以前，我习惯先问问本身为何要作，譬如收益和付出是什么，若是没有想清楚，宁愿不作。

微服务也不例外，咱们不能盲目跟风，必定要结合本身的实际，慎重地决定是否须要微服务化。

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

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

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

然而微服务也会带来不少问题，例如若是设计不合理，总体的复杂度会提升。写代码的时候须要考虑调用失败的状况，须要考虑分布式的事务（固然不少时候是设计不合理致使的），从而对人提出了更高的要求。

总之，微服务带来了不少优点，同时也带来了不少挑战，咱们须要认真的审视本身，这些优点对当下的咱们是不是优点，这些挑战对当下的咱们是否能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

---

欢迎关注咱们的知乎专栏