技术总监张大发在朋友圈看到一篇关于Netflix微服务实践的文章。研究了一会儿，不禁赞叹：每个服务都是一个组件，可以1.独立开发，2.独立部署，3.独立伸缩。Netflix可以在生产环境中随意停止微服务来测试稳定性。张胖子着实惊呆了！张胖子上网搜索了一下，发现网上已经有很多文章了。许多公司已经开始使用微服务并输出了很多最佳实践。绝不能容忍！他立即召集部门开会，讨论微服务转型问题。技术狂热者小王率先发言：“支持微服务的框架有很多，比如SpringCloud、Dubbo等，张总可以选择！”张大发找到支持者，给了小王一个赞许的眼神。想着小李说道：“张总，我们维护的是企业内部的一个系统，看起来并不算太复杂，是不是需要改造为微服务？”张大发问道：“为什么不呢？微服务是行业的未来，不跟风就会被时代抛弃。你以后没做过微服务，你还好意思出门跟别人打招呼？！”没人说话。张胖子补充道：“每个服务都是独立的，你可以用自己喜欢的编程语言来开发！”我想试试Go“小王：”我正在学习JavaScript，我可以得到Node。RPC框架支持服务发现、负载均衡、网关、故障转移等多种功能，随后他带领大家将现有系统划分为12个微服务，通过RESTAPI调用，微服务转型之路正式开启！第一周：小李：“先生。张，现在配置本地环境真的很麻烦。我负责的服务依赖其他五个服务，不能在本地运行。”张胖子：“嗯，这个我事先没想到。我看到大家都在用docker。为什么我们不也为微服务形成一个docker镜像呢？这样每个人都可以在本地运行整个环境。”小李：“这个行得通吗？我机器性能差，这么多微服务跑不起来是吧？”张大发：“没事，我在申请基金，每人一台高性能电脑！”第二周：小王：“先生。张，你看我们每一个微服务都对应着自己的数据库，原来的事务是做不了的。”张大胖吓了一跳，他怎么可能忽略这个问题！他知道分布式事务，两阶段提交，三阶段提交，但是性能差，稳定性不好，侵入性很大，最后决定就用“最终一致性”这样的宝物，送给了小王。小王看了之后说：“先生。张，要实现重试和幂等，真的很麻烦。.张大胖拍了拍小王的肩膀：“小伙子，要开阔眼界，这是多好的学习机会啊？”第三周：小梁：“张老师，微服务那么多，找了一个又一个服务花了一上午，累死了。张胖子很无奈，他找到了一个开源的解决方案叫“LinkTracking”Zipkin，丢给小亮实现。看着密密麻麻的配置，小亮感觉很破。第4周：小蔡：“Mr.张，这些日志文件分布在不同的机器上，查起来很麻烦。”张大法找到了一个“ELK日志分析”的解决方案，丢给小蔡去实施。第五周：小刘：“先生。张小亮改了微服务接口，加了一个参数。他没有给其他人说我们的微服务不能运行了！张大法说：“小亮怎么能这样呢？”小刘：“原来在一个项目中，在编译阶段就能发现接口不匹配的地方。现在都依赖文档约定的接口，再发现问题就来不及了。”张大发找了个“契约测试”，发到群里：“以后服务变更都要通过契约测试！”第6周：小李：“先生。张大胖，我们12个微服务每人部署3个实例，我昨天熬夜才手动部署的，肯定是自动化的，要不我们也有一套k8s？”张大胖拍了拍小李的肩膀：“小伙子有很多想法，微服务做不出来。一定要用k8s吗？我们开始做吧！”经过几个月的996开发，微服务改造的系统隆重上线，各种新技术在其中闪耀：服务发现、负载均衡、网关、故障转移，最后是一致性、链路跟踪、日志分析、契约测试、docker，k8s……张胖子很满意。总裁把张胖子叫进了办公室。CEO：“张胖子，你说要做系统改造，我会还给你批的资金，怎么现在系统越来越慢了？”张胖子：“老大，你不知道，我们现在的系统是分布式的，分布式系统稍微慢一点。”CEO：“我就是想问你，我就是想看看这个报表，为什么不能结果出来很久了？”张大发：“因为我们现在是微服务架构，涉及到多个服务调用！我们实现了网关、负载均衡、故障恢复等很多高级功能，不信每个服务有3个实例。如果我杀了任何一个，系统都会自动启动一个新的，就像Netflix一样……”CEO怒道：“你疯了吗？我们的是一个内部应用程序。公司只有几百人。你们搞负载均衡和failover干什么！”第二天，张大胖被炒了鱿鱼。张大胖对组员说：“哎，没办法，领导只关注业务，不关注公司的发展趋势技术，我走了，以后大家自己做吧。”小李嘀咕道：“这技术不就是用来做生意的吗？微服务看着很美，其实根本不适合我们。”小王道：“先生。“老张，你别听小李瞎说，我们学过微服务，简历里有干货。”单体项目转微服务，精通微服务的架构设计、部署和监控。后记：写这篇短文是为了说明一个道理：人不能“手拿锤子，眼里全是钉子”。微服务虽然好，但也有适用范围。有很多项目单体应用活得好，根本没必要拆分，一味追赶潮流，反而得不偿失。【本文为专栏作家“刘欣”原创稿件，转载请通过作者微信获取授权公众号coderising】点此查看该作者更多好文
