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

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

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

1. 标准的SSH的单体应用， 一个war包打天下，所有的功能都放在一个应用里，这种做法部署和集群部署都比较容易，成本低；

2. 按功能垂直划分的多个子应用。多个war包一起部署，组成一个完整的系统。这种做法灵活度提高了， 可以按功能来划分开发小组；

3. 微服务系统，目前比较流行的是采用spring cloud/dubbo这些微服务框架做前后端的分离开发。横向把前端和后端从人员架构上分离开来，用于减少对人员的综合素质要求。现在前端的技术发展日新月异，已经很难做到一个人能做到前后端通吃，  前端包括IOS、Android、WAP、各种小程序等， 所有前端都要共用同一套后台接口，后端的开发同事只要提供RESTFUL风格的接口，通过swagger等技术手段把接口暴露给前端调用即可。

从一个普通的SSH或者SSM的系统升级上来到底是spring cloud更合适还是dubbo更合适呢？ 因为dubbo曾经停止更新过一段时间，因此目前收到的反馈是大多数公司都会优先选择spring cloud，但是在实践的过程又发现在原有的SSH系统上升级上来的话采用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，所有的服务都在注册中心注册，负载均衡也是通过在注册中心注册的服务来使用一定策略来实现

服务注册中心和配置中心都采用同一个化简了部署的步骤。

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

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

2. 敏捷开发

关于敏捷开发，不得不提的是devops。从百度得来的定义，DevOps（Development和Operations的组合词）是一组过程、方法与系统的统称，用于促进开发（应用程序/软件工程）、技术运营和质量保障（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 原生的，同时也是最简单，最易学，最节省资源的，因此LegendShop把Swarm作为系统的集群部署的解决方案。

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

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

3. 总结

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

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

本文更多的是原理性的阐述，但是所述都是经过在电商系统中实践终结出来的。