微服务是灵丹妙药吗？自2014年以来，“微服务”一词越来越流行。好像Microservices已经out了，那我们先看看微服务。其特点是：组件以服务的形式提供。围绕业务功能进行组织。加强码头，弱化管道。产品而不是项目独立部署。单一责任。去中心化的DevOps和组织结构。我要讲的故事要从A公司的技术架构体系说起，目前还是以集群扩容体系为主。我们可以看下图。在这个架构中，我们可以看到应用是单块结构的，但是单块结构的应用是可扩展的。通过部署在多个Tomcat中的所有应用访问同一个数据库（这个数据库可以假设为Oracle数据库），通过DataGuard实现数据库间的主从同步。阅览库仅具备阅览功能，为后台数据统计功能提供数据。查询和统计服务。目前业务请求并发数为每分钟几十笔交易。看来这个架构还是可以支撑现在的业务发展的。突然有一天客户在做活动，监控中心发出各种告警，很多请求以500tps/分钟的速度超时。监控显示当前服务器无法支持如此大的并发量，于是很快部署了服务器并上线了应用。没用的，跟不加一样，加了几个也一样。运维和DBA发现此时数据库的压力非常大。好不容易熬过了这段时间，团队成员一致认为，目前的架构体系已经无法支撑业务发展，微服务开始快速推进。其中，微服务数据去中心化的核心点是：每个微服务都有自己的私有数据库来持久化业务数据。每个微服务只能访问自己的数据库，不能访问其他服务的数据库。在某些业务场景中，需要在一个事务中更新多个数据库。在这种情况下，你不能直接访问其他微服务的数据库，而是对微服务进行操作。数据的去中心化进一步降低了微服务之间的耦合度。最后经过面向服务的改进，变成了如下图：上图是不是很好看，服务拆分是不是很清晰？所以后来问题来了：以前团队只有10个人，只负责一个2个项目，现在突然增加到平均每人维护两三个项目，线上运维还在使用war包上网。如果有修改过的配置文件，不仅便于运维同学逐一修改。上网是不对的，每次上网都是半夜。按照前面说的数据去中心化的原则，把数据库拆分出来，一台服务器服务一个数据库实例，但是对于后台统计系统来说是噩梦。分库后的统计工作和报表工作怎么办？有些工作还能做吗？有人说可以分开统计，一个库一个库，但是这样的工作量会很大。机房的双活问题仍然是金融公司的一个关键技术指标。对于双活的应用，其实实现起来还是比较容易的，但是对于数据库来说确实是一个技术问题。以Oracle数据库为例，如果你使用Oracle官方提供的OGG（OracleGoldenGate）进行数据同步，根据论坛上查看的资料，可以看到OGG的坑很多，而且很容易丢失数据，更重要的是，它很昂贵。使用Oracle的LogMiner进行同步，同步出来的数据不会是实时的，会有一定的延迟，定时读取的工作需要自己开发。使用Oracle的DataGuard只能做主从同步，不能做主。活跃活跃。所以经过研究，我最终决定独立开发。使用Dubbo或SpringCloud是微服务吗？那么，在使用了Dubbo之后，我发现还有很多工作要做。Dubbo只是一个服务治理框架，还需要开发分布式调用监控系统和统一的配置管理中心。统一定时调度，各服务反重幂等，并发限流，根据不同服务隔离缓存。那我们是不是可以用SpringCloud来做一个统一的集成呢？然后看到SpringCloud有这些坑：注册IP问题。早春云Eureka在注册获取网卡IP时无法区分外网网卡和内网网卡。如果安装了虚拟机和Docker，则无法区分虚拟网卡，每次启动注册的IP可能都不一样。如果要注册为外网网卡IP，那么运行带宽就不够用了。这个bug应该说是一个严重的问题。于是重写了网卡IP获取的逻辑来解决，也反馈给了SpringCloud团队。之后的版本增加了网卡接口排序和名字过滤的功能来解决这个问题。HealthCheck的问题会在一些极小概率的情况下导致EurekaServer的微服务实例下线，出现“RemotestatusfromEurekaserverisdown”的问题。即使重启微服务也无济于事，不过SpringCloud官方GitHub中已经有码友发了解决方案issue。Feign使用不当导致的性能问题，其他小坑可以容忍，大坑就不行了。于是去各大社区讨论，发现大家都重新封装了很多Cloud的组件。回过头来看上面，我用了很多篇幅来各种吐槽，那我们说微服务好吗？我一直坚持认为微服务是好的，但是如果我们为了使用微服务而使用微服务，就会伤害到自己，从单体系统微服务是一个需要逐步演进的过程。如果前期没有调研和统筹规划，后期做的时候会发现需要做的事情越来越多，尤其是对于快速成长的创业型企业。解释。就拿我上面举的例子来说，数据库本身的压力就很大。经过分析可以看出，很多SQL没有建立索引，数据库使用了大量的悲观锁，大表的数据长期积累，没有迁移出去。当单体系统遇到性能问题时，如果仔细分析性能的根本原因，或许可以为我们争取更多的时间向服务化演进。***我想说的是，对于中小型公司来说，如果业务发展很快，人手不足，我们更需要的是在业务发展和架构优化之间取得平衡，逐步演进，而不是快速使用。
