最近看到了一篇介绍微服务理念的文章,恰巧在工作中遇到了需要搭建微服务的场景。
情形是这样的:业务方通过token验证用户权限,用户token存储在单台redis服务器上。DBA为了保证token服务的高可用,打算采用redis cluster来避免单点失败,这需要业务方修改代码。因为用到用户token的业务方不只一个,采用的编程语言也不同,有PHP、nodejs,这样牵扯到的人力资源就比较多,后续的维护成本也比较高。
将用户权限验证做成一个单独的服务是一个合理的解决方案。因为业务方需频繁的调用权限验证接口,需要保证该服务在高并发情形下的性能。
团队目前主要使用PHP作为开发语言,对多种语言编写的服务端程序做了性能测试以后,并考虑了后续的学习成本、维护成本,最终选定了swoole作为底层开发框架。
这样做带来的好处
- 由访问数据库转变为访问接口,由面向实现转变为为面向接口,即使后续采用别的技术实现高可用,甚至采用别的数据库存储用户token,只要保证接口不变,业务方无需做任何改动
- 新增的业务方,只需按照接口约定编写权限验证逻辑
带来的坏处
- 需要服务器部署服务,增加了运维成本
- 由访问数据库转变为访问接口,牺牲了部分性能