罗轶民聊微服务那些事儿，机会多但挑战也不少，真挺复杂的

开始）

罗轶民在聊到微服务的时候，开门见山就说，这玩意儿现在机会是真多，你去招聘网站上看看，凡是跟高并发、大数据量沾边的后端岗位，十个有八个都要求你有微服务经验，他说，这就像当年大家都从功能机换智能机一样，是一种技术架构的升级趋势，你如果不跟上,可能就有点落伍了。

他解释道，微服务带来的最大好处，拆”。（来源：罗轶民技术分享实录）你想啊，以前我们做一个大的单体应用，所有的功能模块，比如用户管理、商品下单、支付流程，全都打包在一个巨大的“战争堡垒”里，这个堡垒一开始挺好，部署简单，但随着业务越做越大，代码量爆炸式增长，问题就来了，哪怕你只想改一行显示的文字，或者修复一个非常小的bug，都不得不把整个庞大的应用重新测试一遍，然后整个部署上线，这个过程非常笨重，效率极低，而且风险很高，俗称“牵一发而动全身”。（来源：罗轶民比喻）

微服务就是来解决这个问题的。（来源：罗轶民讲解核心思想）它的思路是把那个大堡垒拆掉，变成一个个小型的、功能单一的独立哨所，比如用户服务就是一个独立的哨所，只负责用户注册、登录、信息管理；商品服务是另一个哨所，只管商品信息；订单服务又是一个，每个哨所（服务）都有自己的小团队可以独立开发、独立测试、独立部署，甚至可以用不同的编程语言来写，只要它们之间约定好沟通方式就行，这样一来，团队之间的协作就灵活多了，发布速度也快多了，这就是大家常说的“敏捷开发”和“持续交付”的理想状态。（来源：罗轶民阐述优势）

“”罗轶民话锋一转，“你可别以为拆开就万事大吉了，后面的挑战和复杂度，那才是真正考验人的地方，真挺复杂的。”（来源：罗轶民转折强调挑战）

他接着详细说明了这些挑战，第一个大麻烦就是“服务治理”。（来源：罗轶民列举首要难题）以前服务都在一个应用内部，方法A调用方法B，就是个简单的函数调用，现在好了，服务都分散在不同的“哨所”里，这些哨所可能部署在不同的机器上，甚至不同的机房，用户下一个订单，需要先调用用户服务验证身份，再调用商品服务检查库存，最后调用订单服务创建订单，还可能要去调用支付服务，这么一连串的调用，怎么保证它们能互相找到对方？这就是“服务发现”问题，一个服务挂了怎么办？怎么让请求自动转到其他健康的实例上去？这就是“熔断”和“负载均衡”，网络总是不稳定的，调用超时了咋处理？是重试还是直接报错？这些乱七八糟但又至关重要的事情，统称为服务治理，你需要引入像Eureka、Nacos、Consul这样的专门组件来管,学习成本和运维成本一下子就上来了。

第二个让他觉得头疼的是“数据一致性”。（来源：罗轶民谈数据挑战）在单体应用里，可以用一个数据库事务保证数据要么全成功，要么全失败，但现在，用户服务的数据库和订单服务的数据库是分开的，你没法用一个传统的事务把它们绑在一起，比如用户下单扣款成功了，但创建订单时因为网络问题失败了，这就会导致钱扣了但订单没生成，用户肯定要投诉，为了解决这个问题，又得引入“分布式事务”这种复杂的概念，比如Saga模式、TCC模式，或者依靠最终一致性的消息队列，这些东西理解起来就费劲，实现起来更容易出错,对开发人员的要求高了很多。

第三个是“测试和排错的噩梦”。（来源：罗轶民描述运维痛苦）单体应用的时候，你就在本地启动一个服务，调试起来很方便，微服务架构下，你的功能依赖好几个其他服务，想在本地完整地模拟出所有依赖服务来进行测试，非常困难，更可怕的是线上出了问题，一个请求经过了五六个服务才完成，其中有一个环节慢了或者错了，导致整个请求失败，你怎么快速定位到底是哪个服务、哪台机器出的问题？这就需要一个强大的“分布式链路追踪”系统，能把一个请求的完整路径像画地图一样画出来，比如用SkyWalking、Zipkin这些工具,这又是额外的架构复杂度和运维负担。

罗轶民总结说，（来源：罗轶民最终总结）微服务绝不是一种简单的技术，它更像是一套完整的架构哲学和组织方法论，它用服务的“拆分”换来了开发的灵活性和可扩展性，这是它的巨大“机会”，但同时也把原本在单体内部的复杂度，转移到了服务之间的“连接”和“管理”上，带来了运维、测试、数据一致性等一系列“挑战”，他不是反对微服务，而是强调一定要认清它的两面性，对于业务初期、团队规模不大的公司，盲目跟风上微服务，可能就是“杀鸡用牛刀”，反而会被复杂的运维拖累死，只有当单体应用真的臃肿到难以维护，成为业务发展的瓶颈时，再痛下决心进行微服务化改造，才是更明智的选择，这事儿，得想清楚了再干。 结束）