从运维角度说微服务

微服务是去年开始很热门的词汇，有幸碰到老板也想实践微服务的。但是这这中间确实碰到了很多的问题。 首先是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。 最后：微服务的优势就是为了更好更快的扩展，降低服务之间的耦合性，但是对于开发的要求更高了，对于运维的要求也同样更高了。