微服务架构的一些思考

微服务架构的一些思考

微服务

微服务在工作中已经使用了好几年了，从最开始对微服务技术盲目的追从，到逐步的冷静下来，根据团队组织结构，认真分析业务发展选择最优的方案。期间是遇到过很多的坑，目前看到使用微服务带来的最大好处有这几点。

1. 独立部署

提高应用的可扩展性，按需分配资源。同时保证了各服务间的环境隔离，使局部故障的影响最小化；也保证了应用最大资源化和方便管理。

1. 团队协作

单块架构的最大问题，是系统紧密耦合，但是业务发展到一定阶段，必然产生多团队协同开发，于是单块耦合系统和多团队之间就会产生矛盾。多个团队在单块上开发部署，需要很多协同开销，常常还会产生摩擦和打架，严重影响交付效率，把单体拆解成微服务，各个团队可以自治开发/测试/部署各自负责的微服务，相互不干扰(或者干扰很小)，这样可以大大提升交付效率。

但带来的挑战也是很大的，例如独立数据源带来的挑战，拆分前的下单流程，扣减库存，扣减积分，锁定优惠券，保存订单等操作同属一个事务；拆分后属于不同的服务，需要额外流程保证数据一致性。

在如今的互联网时代，企业快速迭代和交付的效能就是竞争力，单体架构太慢太不灵活，难以规模化。微服务架构最终目标是业务的快速迭代和规模化发展。



中台架构：

中台这部分，公司一直都没有去实践，人少事多，项目紧，业务的发展也暂时没打达到需要中台去承载的成都。中台的本质是企业级能力复用平台，提炼各个业务板块的共同需求，进行业务和系统抽象，形成通用的可复用的业务模型，打造成组件化产品，供前台部门使用。前台要做什么业务，需要什么资源，可以直接找中台，不需要每次都去改动自己的底层。当前的计划是先逐步建立以数据共享为基础的数据中台，再在数据中逐步沉淀出业务中台。



领域驱动设计

在DDD这部分，之前在新项目有尝试过一次，如何界定上下文边界，从而提炼出微服务的边界，这部分耗费了很多时间。业务拆分只是其中一小部分，数据拆分才是难点。最后没有DDD的微服务是没有灵魂的。