大型电商系统架构的微服务与敏捷开发实践方法教程

大型电商系统架构的微服务与敏捷开发实践方法教程，针对这个问题，这篇文章详细介绍了相对应的分析和解答，希望可以帮助更多想解决这个问题的小伙伴找到更简单易行的方法。

成都地区优秀IDC服务器托管提供商(创新互联公司).为客户提供专业的四川乐山服务器托管,四川各地服务器托管,四川乐山服务器托管、多线服务器托管.托管咨询专线：13518219792

       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（以下简称SCN）一样，都是Spring Cloud规范的一套实现。看一下他们之间的差异：

       可见这2套系统的原理都一样的， 阿里巴巴的版本想要通过利用spring cloud的生态来拉拢spring cloud的程序员，有点师夷长技以制夷的味道。这个版本提供了一个比较好用的配置中心、注册中心Nacos和熔断器Sentinel， 这些组件能同时兼容spring cloud和dubbo， 为spring cloud和dubbo的融合和同时使用提供了便利性， 而且比以前的组件更强大和更容易使用了。

1. 体系架构

         总结以上的分析，以下是朗尊软件的架构师何文强所带来的技术分享。以LegendShop电商系统为例， 先看一下整体的解决方案：

结合图中所示，下面是这套电商系统所采用的技术的主要的技术栈。

1. 通过 API 的设计解耦，把整个系统根据业务拆分成若干个子系统或微服务

               客户端通过API gateway来访问内部的应用， 通过gateway来实现黑白名单，路由控制，权限控制等。一个后台可以同时支持多个客户端。

    2. 每个子系统可以部署多个应用，多个应用之间使用负载均衡

              每个服务会占用一个端口，同一个服务可以启动多个实例。

    3.  服务注册中心和配置中心都采用Nacos，所有的服务都在注册中心注册，负载均衡也是通过在注册中心注册的服务来使用一定策略来实现，以下是Nacos的截图。

    4.   使用 OAuth3 认证完善外部交互的安全机制

     客户端在调用gateway或者内部API的时候需要系统授权才行，要不就无法保证系统安全。本方案采用Oauth3进行权限验证， 每个调用方都会分配一个appId和secretKey, 用户调用API之前需要用appId和secretKey来换取合法的token，然后通过token来访问系统的功能。OAuth3 是为用户资源的授权提供的一个安全、开放、简易的标准协议。OAuth3 的授权不会使第三方触及到用户的帐号信息，非常安全。而且任何第三方都可以使用 OAuth3 认证服务，在这套架构里，每一次来自外部的对微服务的请求，都要通过 OAuth3 服务器验证。OAuth3 在此统一了众多微服务的安全机制，并且将安全做到了微服务级别而不是网关级别。

   2. 敏捷开发

        关于敏捷开发，不得不提的是DevOps（Development和Operations的组合词）。从百度得来的定义，DevOps是一组过程、方法与系统的统称，用于促进开发（应用程序/软件工程）、技术运营和质量保障（QA）部门之间的沟通、协作与整合。它是一种重视“软件开发人员（Dev）”和“IT运维技术人员（Ops）”之间沟通合作的文化、运动或惯例。透过自动化“软件交付”和“架构变更”的流程，来使得构建、测试、发布软件能够更加地快捷、频繁和可靠。它的出现是由于软件行业日益清晰地认识到：为了按时交付软件产品和服务，开发和运维工作必须紧密合作。

  2.1 版本控制

       开发这块目前是使用git来做版本控制，git的基本用法遵循以下的原则进行裁剪。

Master和develop分支是长期存在的分支，如果有bug出现的话就从打bug分支修改完再合并到develop分支。再由develop分支合并到master分支上，最后出版本从master版本上获取代码即可。

2.2 持续集成

     另外一个持续集成的工具优先采用Jenkins，其截图如下：

Jenkins是一个功能强大的应用程序，允许持续集成和持续交付项目，无论用的是什么平台。这是一个免费的源代码，可以处理任何类型的构建或持续集成。集成Jenkins可以用于一些测试和部署技术。Jenkins是一种软件允许持续集成。

Jenkins跟git/svn等这些代码管理工具紧密工作，方便整个开发和部署。

2.3 Docker部署

由于微服务会分成比较多的独立运行的系统， 如果都是手工部署的话，会比较繁琐。因此不利于系统的长期稳定发展，采用Docker安装的话，会化简整个部署的步骤，并且提高了系统的安全性。系统部署的结构如下：

      每个微服务都是独立运行的一个子系统。

    从百度得知，Docker 是一个开源的应用容器引擎，让开发者可以打包他们的应用以及依赖包到一个可移植的镜像中，然后发布到任何流行的 Linux或Windows 机器上，也可以实现虚拟化。容器是完全使用沙箱机制，相互之间不会有任何接口。 实践中会发现，生产环境中使用单个 Docker 节点是远远不够的，搭建 Docker 集群势在必行。然而，面对 Kubernetes, Mesos 以及 Swarm 等众多容器集群系统，我们该如何选择呢？它们之中，Swarm 是 Docker 原生的，同时也是最简单，最易学，最节省资源的，因此把Swarm作为系统的集群部署的解决方案。

Docker容器应用的开发和运行离不开可靠的镜像管理，虽然Docker官方也提供了公共的镜像仓库，但是从安全和效率等方面考虑，部署我们私有环境内的Registry也是非常必要的。Harbor是由VMware公司开源的企业级的Docker Registry管理项目，它包括权限管理(RBAC)、LDAP、日志审核、管理界面、自我注册、镜像复制和中文支持等功能。

       采用Docker部署各种常规应用非常简单， 只要一条命令或者一个yml文件即可。由于本文不是重点讲解如何使用Docker，因此一笔带过，请参考笔者其他的关于如何安装Docker，Docker-compose、 Docker-swarm的文章。

1. 总结

        系统的升级和优化永无止境，只能根据实际情况不断的调整和优化。微服务带来的好处是能将系统细分为不同的子模块， 适合中大型的系统开发。因为电商系统是跟客户打交道的销售型系统，这个行业性质跟企业内部使用的系统不一样，决定了电商系统要做强做大的话，客户量会有数个数量级的差别。而且客户会提出各种各样的需求，功能和界面也要跟着节日或者潮流来变化。所以这个微服务版本是针对多金客户来使用比较合适，服务器和人力的消耗都比较多。 有些客户一上来就说我要做一个淘宝，做一个京东，我要分表分库。拜托，还是理智一点好。 不过微服务版本的电商系统也给了客户一个能做梦的基础。

        将来的10年是传统线下行业向线上渗透的年代。对一般的中小型客户使用集群版本就可以了。再小一点我只要做生意卖货而已， 没有什么特殊的需求，那就采用SAAS版本就好了。SAAS + PASS才是将来发展的道路， 毕竟专人做专事。

关于大型电商系统架构的微服务与敏捷开发实践方法教程问题的解答就分享到这里了，希望以上内容可以对大家有一定的帮助，如果你还有很多疑惑没有解开，可以关注创新互联行业资讯频道了解更多相关知识。