服务集群化的思考

近期因为工作需要，将原有的分布式系统迁移到docker群集，每个服务会部署多个容器，使用服务发现。
1、整改过程中发现原来进程中类似单例模式的变量访问，其实只要加个锁就可以了，但是如果每个服务部署多个容器，那其实进程内部的全局锁就没什么用了。这个就类似多个进程要公用一个唯一的可变的变量一样，这个时候就需要使用分布式锁或者服务拆分了。
举一个例子，调用微信公众平台的接口一般需要用到一个access_token，这个access_token会有个有效期，如果有效期到了就会失效，同一个系统中有多个进程需要用到access_token，那么就需要管理由一个服务来管理access_token，或者如果多个进程都在同一个主机使用共享内存也可以。如果管理access_token是单实例的，那么其实在管理access_token的进程中加把锁就可以了。但是如果所有的服务都会有个主备的，或者为了减缓服务器压力使用多进程提供相同服务，这时候如果access_token失效的时候，各个进程都去请求新的access_token的时候，就会导致先申请的access_token失效。这个时候就需要将access_token存放到新增的服务，比如redis。然后如果获取到access_token当然就最好，当获取不到的时候，需要加上一把分布式锁，只让一个进程获取access_token以后将获取access_token存到redis上。

2、设计模式主要还是为了软件的解耦，当每个服务都有多个实例，而且可以同时提供服务的时候。这种软件解耦将需要做的更加彻底，或许有些模块原来是直接在进程里面的，集群以后需要把原来的模块服务化。比如配置管理，单实例的时候可能用配置文件就可以了。但是集群了如果不把大量的配置服务化，那服务部署将可能是灾难。比如和数据存取相关的，可能原来会使用工厂模式来应对不同的底层存储。但是集群了以后可能要把数据存取的拆成对应的服务，这样可能业务服务就会知道很多类似数据库方面的信息了。这种数据层面的解耦将会转化为服务间的依赖。

3、日志跟踪必不可少，集群后可能会拆分多多个服务出来，个人觉得，会在一定程度上提高系统的可靠性，但是那些代码严重bug导致服务不可用还有业务逻辑错误这肯定是无法避免的。如果出了问题可能会比传统的单进程更加的难以定位，对后台开发来说，有时候定位问题比敲代码更加重要。

4、缓存的重要性。服务集群化后，多少会增加一些跨节点间的调用，对单次调用性能能会有所损耗。而对于单次请求性能提升最大的其实还是缓存。对于内部服务之间的调用，使用性能比较高的rpc调用也是很必要的。但是要在性能和可扩展性之间做权衡，比如golang标准包中的rpc其实性能还算ok，且开发起来比较快，对第三方包依赖少，但是考虑到服务间后续可能会是跨语言的，可能就会使用grpc更替。

5、各种服务的单元测试将更加重要，由于系统整体会拆分的更加细致，对于测试人员来说可能对应的黑盒子会更加多。不管架构怎么调整，质量永远是在第一位的。