现代电商的特点

• 电商也是商业，商业的本质是竞争，竞争的本质是业务模式的不断迭代着优化和创新，电子商务的迭代速度远快于传统商业，业务快速迭代的过程和结果，均让技术体系的迅速复杂化。
  • 业务复杂化举例：
    1. 需要适配更多的前端：PC网页，手机网页，IOS APP, Andriod APP, 微信公众号，微信小程序，支付宝小程序，京东，淘宝，天猫商铺 … 这个列表还可能不断增长，客户端很多时候就是渠道的代名词，渠道的多少正比与获客的多少，这个是竞争力的一部分，所以不可避免对接的客户端会越来越多。
    2. 电商业务逻辑本身越来越复杂。包括关键的运营手段：优惠活动越来越复杂，组合越来越多…这些复杂的优惠组合甚至直接催生了像”什么值得买”类似优惠爆料整理网站， 电商业务本身也在不停的复杂化，预售，抢购，拍卖等等….
    3. 物流业务处理也变得更加复杂，需要对接多个物流供应商上，多个仓储，如果是出海的电商，还会面临不同货币，关税等的问题。
    4. 售后的对接。售后也是电商业务的主战场之一，售后业务可能带来收入也极大的影响口碑。
    5. 商品采购和库存管理也日益复杂，多个销售渠道，和售后渠道的组合有时甚至让获取当前的准确的销售情况都非常困难，电商业务通常还有预测的需求，根据预测情况提前备货，为各地的仓储提前建立库存。
  • 传统单体架构遭遇日趋复杂的电商业务所面临的困难
    1. 过度的复杂性对开发者的要求大大提高，无论是开发新业务，还是bug修正。保证业务按时，按质的交付，对开发者来说变成了有极大焦虑感的事情。焦虑感的提高，会降低工作的效率和质量。复杂度还是不断累积，陷入恶性循环。

    

    开发人员是软件过程最重要的参与者。对于开发者，没有开发者能理解一个复杂的单体系统的全部，因此对问题的修复和新功能的开发变成了一件耗时，困难，焦虑，需要运气加持的一件苦差。

    1. 对于项目管理者极大增加了成本和进度风险。一方面对于要勉强维持复杂的系统，需要招聘更优秀的的开发人员。而招聘本来就是件困难且具有高度不确定性的事情。同时，即使在项目划分为多个项目组并使用scrum等 敏捷开发实践，为了保证项目集成。所有的敏捷开发团队还是需要在同样的进度节奏上做特性开发，code freeze,测试，集成测试，部署等等，任何一个团队延误会影响整个发布计划。这给项目管理带来了巨大挑战，不同子项目组之间的依赖集成关系也会给项目管理组带来巨大的负担。

       

    2. 交付的可靠性得不到保证

    3. 性能难以扩展 应用的不同部分对资源的的性能要求是非常不同的。如有些部分需要大内存，快速访问，比如应用有自己的大型缓存。有些部分需要数据的高速持久化，需要高IOPS。比如事务的提交。有些部分是CPU密集性的，需要在高CPU的性能机器上需要部署多份比如推荐系统。 对于单体应用，需要以所有部分的对资源不同属性的最高要求为标准，并且以对机器数量最高的要求为标准。对上面的例子，你需要多台大内存，高IOPS, 高cpu的机器才能部署，但面对突增的流量时，也没有办法。
    4. 重构无法进行，技术栈几乎无法更新。无法享受技术发展的红利

解决方案–微服务架构

• 微服务架构的解决上述实践问题方法实质上就是我们一直在说的”高内聚，低耦合”的策略进一步实现。微服务是进程级别的解耦合，把应用再划分成更小的能独立开发部署的子应用，是最高级别的接耦。
• 理解”独立子应用”，最高级别，这两个关键词非常重要，你可以回答这样的问题，在微服务架构中，是一个微服务对应一个数据库，还是多个微服务对应一个数据库。
• 微服务架构能解决的问题总结:
  1. 通过架构影响习惯，解决复杂性问题
  2. 解决项目质量属性里面的非功能性属性：包括可维护性，可扩展性，可测试性，低成本，快速交付。

     电商抢购场景的分析

     1. 电商抢购场景是复杂的，既要保证抢购时，系统的响应速度，和吞吐速度。所以需要对抢购的业务代码做大量的优化，改动。同时如果在改动中引入了BUG,因为抢购场景成交巨大，所以Bug的影响巨大。 这样的特性微服务架构，可以让抢购的微服务，和系统的其他部分更彻底的隔离。所以微服务架构，对这样的场景减少了风险的情况。
     2. 抢购场景对性能的要求较高，通常需要对抢购的模块使用更高性能的硬件。通过微服务将其隔离出来。可以尽量节省成本。
     3. 抢购场景对性嫩的伸缩性要求较高，通常的场景是，平时用较少的硬件基础设置，等到快要举行抢购的前期，扩容。