微服务架构在常州大型软件开发项目中的实践与挑战

　　当项目大到一定程度，单体应用就像一团乱麻：改一行代码要测全量，加一个功能要重启整个系统。微服务架构应运而生，但转型之路并非坦途。常州大型软件项目在这条路上走得早，经验也深。

　　为什么拆？

　　传统单体应用，所有功能在一个代码库。几十个人一起开发，合并代码天天冲突；流量一高，某个模块卡死，整个系统瘫痪。微服务把系统拆成几十个独立服务：用户服务、订单服务、商品服务、支付服务……每个服务独立开发、独立部署、独立扩容。改订单服务不影响用户服务，订单服务挂了也不影响其他服务。

　　怎么拆？

　　常州信息职业技术学院的课程以""SweetFlower商城""为案例，讲授Spring Cloud框架。这是国内最主流的微服务解决方案。通过服务注册发现（Eureka）、配置中心（Config）、网关（Gateway）、断路器（Hystrix）等一系列组件，把分布式系统的复杂性封装起来，让开发者感觉还在写单体应用。

　　实践中的挑战。

　　分布式事务是最大难题。原来在一个数据库里，ACID保证数据一致。现在拆成多个库，下单要扣库存、减优惠券、增积分，三个服务三个库，怎么保证要么全成功要么全失败？Seata这类分布式事务框架能解决，但性能有损耗，需权衡。

　　链路追踪也很头疼。用户一次请求，可能经过十几个服务，出问题到底在哪儿？SkyWalking这类工具能记录完整调用链，哪个环节慢了，一眼看出。

　　适合谁？

　　微服务不是银弹，项目初期不建议上。几十人的小团队、日均几百的流量，单体足够。等到业务复杂到单体难以维护、流量大到单机扛不住，再考虑拆分。常州大型制造企业、连锁商业集团，往往是这时候找上我们。

　　微服务架构，是幸福的烦恼。拆之前痛，拆的过程痛，拆顺了，就再也不想回去了。