看来微服务就是一把双刃剑

栏目: 数据库 · 发布时间: 7年前

内容简介:看来微服务就是一把双刃剑

微服务是银弹吗?自2014年“微服务”一词真是越来越火,不谈Microservices彷佛就out了,那么我们先来看微服务具有哪些特点:

  • 组件以服务的形式提供
  • 围绕业务功能进行组织
  • 强化终端与弱化管道
  • 产品而不是项目
  • 独立布署
  • 单一职责
  • 去中心化
  • DevOps与组织架构

我要讲的故事开始了

A公司的技术架构体系目前还是以集群扩展体系为主,我们可以看下图所示,在这种体系结构中,可以看到应用都是单块结构,但是单块结构的应用具有扩展性,通过布署在多个Tomcat上实现应用的集群,所有的应用都去访问同一个数据库(这个库可以假设为Oracle数据库),数据库间采用DataGuard来实现主从同步,读库只具有读取功能,为后台数据统计功能提供数据查询和统计服务。目前业务请求的并发量每分钟有几十笔交易,看起来这套架构还是能够支撑目前的业务发展的。

看来微服务就是一把双刃剑

突然有一天客户在做活动的时候,监控中心各种告警,在每分钟500tps的时候很多请求超时,监控显示目前的服务器不能支撑这么大的并发量,于是快速增加服务器布署应用上线,发现根本没用,加了和没加一样,加几台都一样,运维和DBA发现此时的数据库压力非常大,好不容易熬过这段是时间后,团队成员痛定思痛一致认为,目前的架构体系已经不能支持业务的发展,微服务开始快速推进。

其中微服务的数据去中心化核心要点是:

  • 每个微服务有自己私有的数据库持久化业务数据。
  • 每个微服务只能访问自己的数据库,而不能访问其它服务的数据库。
  • 某些业务场景下,需要在一个事务中更新多个数据库。这种情况也不能直接访问其它微服务的数据库,而是通过对于微服务进行操作。
  • 数据的去中心化,进一步降低了微服务之间的耦合度。

最终经过服务化改进后,变成了如下图所示的样子:

看来微服务就是一把双刃剑

上图看起来是不是很棒,服务拆分是不是很清晰?

于是问题随后就来了:

  1. 以前团队一共就10个人只负责一二个项目,现在突然增加到平均每人维护二三个项目,上线还是采用由运维手工打war包上线,如果有修改的配置文件,则运维同学一台一台的进行修改,不仅容易上线出错,而且每次上线都会搞到半夜。
  2. 根据上面提到的数据去中心化原则,数据库拆分出来了,一个服务一个数据库实例,但是对后台统计系统来说就是恶梦,数据库拆分出来了统计工作、报表工作该怎么办呢?这部分工作还做不做呢?有人说可以分开统计啊,一个库一个库的来,可是这样的工作量将是巨大的。
  3. 机房的双活问题,对于金融公司来说双活还是很关键的一项技术指标,对于应用双活来说,其实还是比较容易实现,但是对于数据库来说确是一个技术问题了,对于Oracle数据库来说,用Oracle官方提供的OGG(Oracle GoldenGate)来进行数据同步的话,根据论坛上面查看的资料可以看出,OGG坑非常多,而且也容易丢数据,更重要的是贵。采用Oracle的LogMiner来进行同步,同步的数据将不是实时的,会有一定延时而且在定时读取方面的工作上还需要自己进行开发,采用Oracle的DataGuard也只能做主从同步,却不能做主主双活。于是通过调研过后,最终还是决定自己独立开发。
  4. 使用Dubbo或者Spring Cloud就是微服务了吗?好吧,使用了Dubbo以后发现还有非常多的工作需要做,Dubbo只是一个服务治理框架而已,还需要开发分布式调用监控系统、统一配置管理中心,统一定时调度,还要在每个服务中做防重幂等,还要做并发限流,缓存也要根据不同的服务做隔离等等工作。

那我们用Spring Cloud做一个大一统的整合可以吗?于是看到Spring Cloud原来有这些坑啊:

  • 注册IP问题
    早期的Spring Cloud Eureka在注册获取网卡IP时,不能区分外网网卡和内网网卡,如果安装了虚拟机和 Docker 也不能区分虚拟网卡,每次启动注册的IP都有可能不一样,如果要注册为外网网卡IP,那运行带宽就不够,这个bug应该说是比较严重的问题,因此重写了网卡IP获取的逻辑来解决,同时也反馈给了Spring Cloud团队,再后期的版本中添加了网卡接口 排序 和通过名称过滤的功能来得到解决。
  • HealthCheck的问题
    在一些极小概率的情况下,会导致Eureka Server下线微服务实例,出现“Remote status from Eureka server is down”的问题,即便是重启微服务也无济于事,不过已经有码友在Spring Cloud 官方GitHub贴出了解决方法的issue。
  • Feign使用不当带来的性能问题
    其他的小坑也就忍了,大坑却不能。于是去各大社区讨论发现原来大家都对Cloud的不少组件进行了二次封装。

回顾一下

上面用了很大的篇幅各种吐槽,那么我们说微服务好吗?我一直坚持认为微服务很好,但是如果我们为了使用微服务而使用的话将会伤其自身,从单块系统到微服务的是需要逐步演进的过程,如果前期没有调研,没有一个整体规划,后期在做的时候会发现,需要做的事情只会越来越多,尤其是对于快速发展的创业型公司来说。

就拿我上面举的例子来看,数据库自身压力大,经过分析看出其实是很多 SQL 没有加索引,大量使用数据库悲观锁,大表的数据一直长期积累没有迁移出去所致。当单块系统遇到了性能问题后,如果认真分析了性能的根源,也许还会为我们做服务化演进争取了更多的时间。

最后想说一句,对于中小公司来说,如果业务发展非常快速,人员不足的情况下,我们更需要的是在业务发展和架构优化间做平衡,逐步演进,而不是快速使用。

原文链接: 看来微服务就是一把双刃剑


以上就是本文的全部内容,希望本文的内容对大家的学习或者工作能带来一定的帮助,也希望大家多多支持 码农网

查看所有标签

猜你喜欢:

本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们

函数式算法设计珠玑

函数式算法设计珠玑

Richard Bird / 苏统华、孙芳媛、郝文超、徐琴 / 机械工业出版社 / 2017-4-1 / 69.00

本书采用完全崭新的方式介绍算法设计。全书由30个珠玑构成,每个珠玑单独列为一章,用于解决一个特定编程问题。这些问题的出处五花八门,有的来自游戏或拼图,有的是有趣的组合任务,还有的是散落于数据压缩及字串匹配等领域的更为熟悉的算法。每个珠玑以使用函数式编程语言Haskell对问题进行描述作为开始,每个解答均是诉诸于函数式编程法则从问题表述中计算得到。本书适用于那些喜欢学习算法设计思想的函数式编程人员、......一起来看看 《函数式算法设计珠玑》 这本书的介绍吧!

HTML 压缩/解压工具
HTML 压缩/解压工具

在线压缩/解压 HTML 代码

RGB转16进制工具
RGB转16进制工具

RGB HEX 互转工具

HTML 编码/解码
HTML 编码/解码

HTML 编码/解码