与大部分企业的服务化的演进之路如初一辙
单体应用阶段
单体应用，所有的服务跑在一个war包中，这个war包200多MB。之后遇到了如下的问题
- 数据库的链接到了瓶颈：因为所有的程序在一个war包中，这个工程的数据库连接池非常大，已经逼近了单机数据库的连接池的上限；
- 所有功能耦合在一起：牵一发而懂全身，很可能一个小改动就引起宕机;
- 性能问题：没法做业务的隔离，一个接口慢，会拖垮整个项目
- 业务膨胀导致没有一个人能了解所有的代码，祖传代码盛行。
服务化
飞行中换发动机，采用去中心化的分布式架构逐步用服务替换掉单体应用。
淘宝的微服务化
淘宝采用去中心化的微服务架构。与之相对的是中心化架构，著名的“ESB”架构，这个架构有个致命的问题，ESB作为真个架构的路由，所有的服务都会落在ESB上，那么他就会成为整个系统的瓶颈，维护成本很高，并且会制约业务发展。这些是互联网业务无法容忍的，所以淘宝就采用了HSF这种去中心化的分布式架构，服务直接点对点的直接调用。（它的特点naming服务只做服务发现、订阅和配置更新的推送，在服务之间大量的请求并没有走naming）。
这种架构也就是现在的微服务架构，因为它：
- 以服务方式提供应用
- 以服务的方式而非项目的方式组织架构
- 通过服务的只能编排提供业务支撑
智能运维，以及健壮的平台稳定性（降级、限流、熔断）
当然微服务话我们也要接受如下挑战：
服务的管控：服务的配置中心，服务的全链路跟踪等需要支持否则排错，自我运维闭环是无法实现的；
- 分布式事务的支持：与单体不同，对于数据一致性要求高的场景我们要想办法支持分布式事务的场景;
- 只能运维的支持以及平台稳定性挑战;
- 组织架构的变化：要根据服务特点组织组织架构的变化;
演进史
建立共享服务中心，前期根据业务拆分了4个中心用户中心，商品中心，交易中心，店铺中心。
用户中心
改造成本低相较于其他模块功能简单，受益巨大上游调用次数多，所以是很好的🕙。