为什么要微服务化？

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

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

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

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

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

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

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

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

这里有几点心得：

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

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

要有架构组，架构组要负责微服务的基础设施的建设，例如 CI/CD系统， Kubernetes 集群，Service Mesh 集群，监控报警系统，日志收集系统，基础的工具和库的构建和维护。业务团队(无论是写基础业务的还是其他业务的)能从架构组那里得到一个稳定可靠的 PaaS以及一揽子配套工具
每个微服务要有固定的团队负责(实践中，可以是对微服务分组，每组微服务对应一组特定的人)。每个团队都要有人负责 DevOps 全套流程，包括 CI/CD 的使用，Kubernetes yaml 的维护，组内权限的分配，监控报警的响应等等。每个团队都对自己负责的微服务全权负责(从开发，到上线，到维护，到调优)。总之，每个团队要对自己的微服务全权负责

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

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

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

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

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