大型电商系统架构的微服务与敏捷开发实践之路

Java电商系统的架构10年前还是SSH的天下，那时候基本都是采用Strurt + Spring + Hibernate/Mybatis这些当时当时最流行技术来构建。但是这个世界没有一招鲜的事情， IT技术的发展比其他行业都要快， 新旧知识的迭代特别快，很多流行的技术就只是流行一段时间又快速的凋零，导致系统要不断的更新其技术体系以保证其技术的先进性。由于旧知识很快要过保质期，导致很多IT人员要不断的积累和学习新的知识，稍有松懈马上就会遇到中年危机。 中年危机的本质是由于身体、家庭的原因导致学习新知识的速度和意愿都下降了， 知识积累的速度和范围跟不上时代的发展，所以很多IT从业人员在35-40岁就要被迫离开这个行业了。这个是很残酷的话题，但是正因为这个行业发展比较快，所以才给新人带来各种机会，给小公司带来弯道超车并成功的可能，只要抓住一个点不断的发力去打磨，就算是大公司再多的资本也是无法应对，因为那个突破点太多了，不可能每个点都能面面俱到。资源投入到那个方向和执行力如何决定了一家公司的高度。

以上说明了信息科技这个行业，变化是唯一不变的真理。我们能做的只是不断的拥抱变化， 想要一劳永逸、一夜暴富的心态还是要不得。

言归正传，在互联网产业飞速变革的今天，系统的架构也要不断的发展，才能发挥更好的开发效率。一般的系统会经历了以下几个阶段的架构变化。

1. 标准的SSH的单体应用， 一个war包打天下，所有的功能都放在一个应用里，这种做法部署和集群部署都比较容易，成本低；
2. 按功能垂直划分的多个子应用，多个war包一起部署，组成一个完整的系统。这种做法灵活度有所提高， 可以按功能来划分开发小组；
3. 微服务系统，目前比较流行的是采用spring cloud/dubbo这些微服务框架做前后端的分离开发模式。横向把前端和后端从人员架构上分离开来，用于减少对人员的综合素质要求。现在前端的技术发展日新月异，已经很难做到一个人能做到前后端通吃，前端包括IOS、Android、WAP、各种小程序等， 所有前端都要共用同一套后台接口，后端的开发同事只要提供RESTFUL风格的接口，通过swagger等技术手段把接口暴露给前端调用即可。

从一个普通SSH/SSM架构的系统升级上来到底是spring cloud更合适还是dubbo更合适呢？ 因为dubbo曾经停止更新过一段时间，因此目前收到的反馈是大多数公司都会优先选择spring cloud，但是在实践的过程又发现在原有的系统上升级上来的话采用dubbo会更容易修改，但是新系统的话还是会优先选择采用spring cloud，因为spring cloud的生态更加完善。但是阿里最近又在重新维护dubbo，并且新开源了一套叫spring cloud alibaba的开源微服务产品，Spring Cloud Alibaba和Spring Cloud的关系是怎么样的呢？ Spring Cloud Alibaba（以下简称SCA）和Spring Cloud Netflix（以下