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

前言

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

正文

1.拆分前

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

2.拆分中

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

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

3.拆分后

3.1. 服务连接问题

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

3.2. 缓存问题

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

3.3. 上线时的k8s配的超时时间的问题

    运维先了解了我们本地启动大概不到30s，所以他们在k8s中的健康检查也配了40s左右。结果发现服务一直重启，日志又没有报错。

运维找到开发说服务有问题，开发也定位不到问题，最后才排查出是健康检查的问题。

3.4. 路由问题

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

3.5. 缓存脏数据问题

    今天刚发现的问题。。很尴尬。由于我们服务代码是从主服务copy过来并进行相应的删减的。。。。
    **共享内存问题**

4.完善中

第三小节只介绍了将某个业务模块拆成一个微服务过程中出现的问题，
本节则主要关注于整个微服务环境治理中出现的问题及响应的解决方案。

总结

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

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