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

微服务是银弹吗？自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的不少组件进行了二次封装。。。

回顾一下

上面用了很大的篇幅各种吐槽，那么我们说微服务好吗？我一直坚持认为微服务很好，但是如果我们为了使用微服务而使用的话将会伤其自身，从单块系统到微服务的是需要逐步演进的过程，如果前期没有调研，没有一个整体规划，后期在做的时候会发现，需要做的事情只会越来越多，尤其是对于快速发展的创业型公司来说。另外针对项目上线的问题，根据微服务的发展来说使用devops进行CI和CD后就可以解决现有问题，还可以采用Docker解决容器化问题，但围绕微服务所做的周边工作确实巨大的工作量，换句话说，我们不懂Docker怎么办，这就需要大量的时间来做研究和试错，当然如果公司很有钱也可以购买这样的服务，总之成本是很高的。

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

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