微办事是银弹吗?自2014年“微办事”一词真是越来越火，不谈Microservices似乎就out了，那么我们先来看微办事具有哪些特点：
- 组件以办事的情势供给
- 环绕营业功能进行组织
- 强化终端与弱化管道
- 产品而不是项目
- 自力布署
- 单一职责
- 去中间化
- DevOps与组织架构
我要讲的故事开端了
A公司的技巧架构体系今朝照样以集群扩大体系为主，我们可以看下图所示，在这种体系构造中，可以看到应用都是单块构造，然则单块构造的运器具有扩大性，经由过程布署在多个Tomcat上实现应用的集群，所有的应用都去拜访同一个数据库(这个库可以假设为Oracle数据库)，数据库间采取DataGuard来实现主大年夜同步，读库只具有攫取功能，为后台数据统计功能供给数据萌芽和统计办事。今朝营业请求的并发量每分钟有几十笔交易，看起来这套架构照样可以或许支撑今朝的营业成长的。
忽然有一天客户在做晃荡的时刻，监控中间各类告警，在每分钟500tps的时刻很多请求超时，监控显示今朝的办事器不克不及支撑这么大年夜的并发量，于是快速增长办事器布署应用上线，发明根本没用，加了和没加一样，加几台都一样，运维和DBA发明此时的数据库压力异常大年夜，十分艰苦熬过这段是时光后，团队成员痛定思痛一致认为，今朝的架构体系已经不克不及支撑营业的成长，微办事开端快速推动。
个中微办事的数据去中间化核心要点是：
- 每个微办事有本身私有的数据库持久化营业数据。
- 每个微办事只能拜访本身的数据库，而不克不及拜访其它办事的数据库。
- 某些营业场景下，须要在一个事务中更新多个数据库。这种情况也不克不及直接拜访其它微办事的数据库，而是经由过程对于微办事进行操作。
- 数据的去中间化，进一步降低了微办事之间的耦合度。
最终经由办事化改进后，变成了如下图所示的样子：
上图看起来是不是很棒，办事拆分是不是很清楚?
于是问题随后就来了：
- 以前团队一共就10小我只负责一二个项目，如今忽然增长到平均每人保护二三个项目，上线照样采取由运维手工打war包上线，如不雅有修改的设备文件，则运维同窗一台一台的进行修改，不仅轻易上线掉足，并且每次上线都邑搞到半夜。
- 根据膳绫擎提到的数据去中间化原则，数据库拆搀扶来了，一个办事一?数据库实例，然则对后台统计体系来说就是恶梦，数据库拆搀扶来了统计工作、报表工作该怎么办呢?这部分工作还做不做呢?有人说可以分开统计啊，一个柯一?库的来，可是如许的工作量将是巨大年夜的。
- 机房的双活问题，对于金融公司来说双活照样很关键的一项技巧指标，对于应用双活来说，其实照样比较轻易实现，然则对于数据库来说确是一个技巧问题了，对于Oracle数据库来说，用Oracle官方供给的OGG(Oracle GoldenGate)来进行数据同步的话，根据论坛膳绫擎查看的材料可以看出，OGG坑异常多，并且也轻易丢数据，更重要的是贵。采取Oracle的LogMiner来进行同步，同步的数据将不是及时的，会有必定延时并且在准时攫取方面的工作上还须要本身进行开辟，采取Oracle的DataGuard也只能做主大年夜同步，却不克不及做主主双活。于是经由过程调研过后，最终照样决定本身自力开辟。
- 应用Dubbo或者Spring Cloud就是微办事了吗?好吧，应用了Dubbo今后发明还有异常多的工作须要做，Dubbo只是一个办事治理框架罢了，还须要开辟分布式调用监控体系、同一设备治理中间，同一准时调剂，还要在每个办事中做防重幂等，还要做并发限流，缓存也要根据不合的办事做隔离等等工作。
那我们用Spring Cloud做一个大年夜一统的┞符合可以吗?于是看到Spring Cloud本来竽暌剐这些坑啊：
早期的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的不少组件进行了二次封装。
回想一下
膳绫擎用了很大年夜的篇幅各类吐槽，那么我们说微办事好吗?我一向保持认为微办事很好，然则如不雅我们为了应用微办事而应用的话将会伤其自身，大年夜单块体系到微办事的是须要慢慢演进的过程，如不雅前期没有调研，没有一个整体筹划，后期在做的时刻会发明，须要做的工作只会越来越多，尤其是对于快速成长的创业型公司来说。
推荐阅读
【51CTO.com快译】作为一名技巧编辑，我在工作中经常与人评论辩论他们的容器化计谋。在刚开端接触容器的时刻，人们老是欲望获得容器技巧所带来的利好，而没有想到过破坏性容器。他们可能有>>>详细阅读
本文标题：看来微服务就是一把双刃剑
地址：http://www.17bianji.com/lsqh/35777.html
1/2 1
网友点评
精彩导读
科技快报
品牌展示