微服务拆分及上线中遇到的几个问题

前言

本篇文章不介绍微服务的理论基本。主要围绕以下几点： 1.拆分前(公司项目的现有的结构以及为什么需要微服务)； 2.拆分中(拆分过程中的主要原则和相关技术支持)； 3.拆分后(服务上线过程中遇到的问题及解决方案)

正文

1.拆分前

公司项目是一个SAAS化的服务产品，为企业提供一些特定领域的解决方案由此收取一些报酬并盈利。 公司的组织架构是：总部是在南方，有好几个研发部门，我所在的部门在苏州。 痛点是整个项目共用一个git仓库，发版和本地编译及其痛苦，发版时如果在测试环境不及时测出问题，等到线上才发现的话，会会滚版本，会把别的部门的好的代码也会滚掉。

2.拆分中

把代码copy一份到新的git仓库，然后删减掉本服务无关的代码，服务建通过grpc通信，就是这么简单

• 1.grpc的一些默认值的问题，很坑

3.拆分后

• 1.服务连接问题 测试环境发现服务上线下线的过程中，其他服务会连接不到，就一瞬间的事情。 我们目前的服务发现的架构是基于etcd来做的。每个服务会在启动时连接并订阅etcd的某个目录，用来监听其他服务的上下线，其他服务的ip/port等信息会保存到一个map中，rpc请求时会根据服务名从这个map中取到服务的具体信息，然后连接并通信。具体哪个环节出现问题的还不太清楚。 解决方案是走的k8s的服务发现。

• 2.缓存问题 缓存是基于redis的发布订阅来做服务间的同步更新的。我们redis的架构采用的是哨兵主从的模式。 发现有时服务A改了某个东西后，服务B没有及时更新到，怀疑是主从切换导致的问题，服务A删除redis1（主）的缓存，结果redis1瞬间失效，redis2成为主，结果1的数据还没有更新到2上来。然后服务B查redis，发现redis上的错误数据。 解决方案是改成了rpc通信，不走缓存同步。

• 3.上线时的k8s配的超时时间的问题 运维先了解了我们本地启动大概不到30s，所以他们在k8s中的健康检查也配了40s左右。结果发现服务一直重启，日志又没有报错。 运维找到开发说服务有问题，开发也定位不到问题，最后才排查出是健康检查的问题。

• 4.路由问题 原来所有路由都是主服务A中，现在切出了服务B，部分路由需要跳到服务B，考虑到工作量的问题就简单在nginx里配了一下路由规则，结果就来坑了。原来是服务A的某个接口路由到了服务B。 解决方案是前端在服务B的接口前统一加/servieB/api/XXX。

总结

公司存在即意味着业务会一直拓展，意味着代码会越来越庞大。其实我们公司以前的项目一定意义上也算是微服务，弊端在于一个仓库要管理所有的服务代码。 微服务拆分上线时最好能灰度发布，（价值小的用户先上。。。），避免影响到所有用户（充钱多的不能惹）。

还有很多别的问题，有空再更新。