微服务是去年开始很热门的词汇,有幸碰到老板也想实践微服务的。但是这这中间确实碰到了很多的问题。

首先是api的规范问题,这也是从运维角度来说最重要的部分。

由于之前是单jar包的方式,原先的开发者也不关注api的规范,导致api的URL完全是凭感觉编的,这个在拆分服务的时候就特别头疼。

/api/stat/1 是指向A服务

/api/stat  又是指向B服务

另外一个是输入和输出的问题,api最关键的是保证输入输出能够长期保持一致,就跟你用第三方的api,你总不能让你新增加的response啥的吧,或者json里再增加点新的内容,当然在公司内部,我们还是可以商量的,但是不能今天这个API是做这个功能,明天就变成B功能了。 这个就很头疼了。

配置文件的统一管理,这个因为拆分成很多服务了,所以再也不能一个配置文件解决所有的问题了,那统一起来管理还是很有必要的了。

基础服务saas化(比如redis,cassandra, kafka,  MySQL),这些基础通过程序包装起来供程序来申请资源,调用,容灾,升级等。这个也是对于原先的运维团队工作量最大的地方。但是也是必须的。

因为拆分成微服务后,各个服务都可能需要用到redis,是分个大redis池,还是每个服务单独一个池子呢? 在微服务领域一般都是一个服务给一个池子,但是不应该一概而论的。我们还是要综合评估的。不能为了微服务而微服务的。

日志的汇总收集,展示。这个标准做法就是通过ELK来完成了,当然我们还用到了kafka来做这个。不过前期是做好日志格式的定义。还有别忘记分了新服务出来后要reload下日志插件,不然都还是找的老的服务。这个就扔部署脚本里一起做了。

在实际使用中发现 consul缺乏服务使用率情况,这个现在是通过监控去收集各个服务的信息再汇总到grafana中,后期是想通过kong来做api调度,然后通过这样的https://getkong.org/plugins/runscope/ 插件来实时查看。

而且consul要跟upsync模块结合的话还要自己写程序去迁移consul中service的内容到kv中,这个实时性就不高了。后面准备自己写入和删除kv。

最后:微服务的优势就是为了更好更快的扩展,降低服务之间的耦合性,但是对于开发的要求更高了,对于运维的要求也同样更高了。

 

Share Your Thought