微服务架构下电商平台的研究和实现
来源:用户上传
作者:
摘要：近年来，随着互联网行业的迅猛发展，公司和业务的不断扩展，使得原本一个小型而简单的应用变得十分复杂，一旦一个小型的应用成长为一个庞大而复杂的单体，开发很有可能将陷入一个原地踏步的境地，为了解决单体应用的问题，我们采用近几年流行的微服务架构的方式来进一步实现电商平台的高内聚，低耦合，提高开发效率。
关键词：B/S架构;电商平台;SpringCloud;持续集成;云原生;微服务;Docker容器;MySQL数据库
中图分类号：TP31 1.5 文献标识码：A
文章编号：1009-3044（2020）10-0288-02
1研究背景及研究内容
1.1研究背景一陷入焦油坑的单体应用模型
近年来，随着互联网行业的迅猛发展，公司和业务的不断扩展，需求的快速变化以及用户量的不断攀升，以及随着SSH和SSM框架的成熟，一个传统项目的开发似乎已经进入一个非常简单的方式。然而，成功的应用程序都有一个趋势，随着时间的推移业务量逐渐增多，需要修改的地方也就越来越多，这就意味着需要添加更多的代码，这种添加的代码量使得原本一个小型而简单的应用变得十分复杂，一旦一个小型的应用成长为一个庞大而复杂的单体，开发很有可能将陷入一个原地踏步的境地，甚至在修改一处BUG后，带来更多的BUG。为了修改更多的问题，又会产生更多的代码，如此恶性循环，使得产品陷人焦油坑最终成为一个不可思议的大泥球。当产品陷入焦油坑而不能自拔时会来带来更多的问题，原本重启服务耗时五十秒，那么在添加了大量代码后，重启时间可能会达到三分钟之长，使得开发变得愈加困难。
1.2研究内容
1.2.1微服务解决复杂难题
为了解决单体应用的问题，也出现了一系列架构来解决这些问题，我们从单体架构走向分布式架构再走向SAO面向服务架构。直到2014年当今世界软件开发领域具影响力的大师Martin Fowler与James Lewis共同提出了微服务的概念，定义微服务架构，将微服务架构推到了一个时代浪尖。我们将一个传统的庞大的业务进行拆分，拆分原则可按照业务来进行划分，如果过于复杂我们可以采用DDD领域驱动设计来进行划分。将庞大的业务拆分成若干个小的业务，各个业务之间内部采用RPC的方式来进行通讯，对外部则采用REST风格的API进行通讯。从而将一个大型应用分解为若干个小型应用通过对模块解耦来解决问题。
1.2.2云原生架构下的微服务实践
2010年5月28日WSO2的CTO和联合创始人在他的一篇博客中首次提出了CloudNative这个概念，2014年Nelflix的云架构师Adrian Cockcroft介绍了基于Cloud Native的成功应用，吸引了大批开发人员争相模仿。我们在向微服务架构的转型中将会出现各种各样的问题，云原生的敏捷基础设施以及公共基础设施将成为一个微服务是否成功的关键。为此出现了代替虚拟机的容器Docker，持续集成私有云平台gitlab，docker镜像管理平台DockerRegistry等。为此，此次研究我们结合云原生与微服务，来做到真正的微服务架构。
2系统总体要求
2.1系统框架要求
1）开发环境。操作系統：Windows 10 Enterprise;开发工具：InteHii IDEA;数据库：MySQL 5.7.22;
2）部署环境。操作系统：LinuxUbuntuServer 16.04X64;虚拟化技术：VMware+Docker;
3）项目管理工具。项目构建：Maven+Nexus;代码管理：Git+GitLab;镜像管理Docker Registry;
4）后台主要技术。核心框架：Spring Cloud+SpringBoot;视图框架：Spring MVC;页面引擎：Thymeleaf;ORM框架：tk.myba-tis简化MyBatis开发;数据库连接池：Alibaba Druid;数据库缓存：Redis Sentinel;消息中间件：RabbitMQ;接口文档引擎：Swag-ger2 RESTful风格API文档生成;分布式日志系统：ELK（Elastic-Search+Logstash+Kibana）;反向代理负载均衡：Nginx;
5）前端主要技术栈：前端框架：Bootstrap+jQuery或者ele-mentui+vue;
6）自动化运维：持续集成：GitLab;持续交付：Jenkins。
2.2硬件的支持要求
运行本系统的硬件最低要求：CPU：3.0Hz;内存：16G;硬盘：256G。
2.3系统架构图
图1为系统架构图。
3系统设计与实现
微服务架构主要在于其思想，正所谓，有道无术，术尚可求，有术无道，止于术，可见思想的重要性。而各种基础设施的搭建和敏捷开发的实现都将成为系统能否架构成微服务的关键因素，业务的开发不再是微服务架构的难点。因此我们将实现一个电商平台来对微服务架构进行研究，对于此电商平台的前台展示页面我们采用Bootstrap+iQuery框架来进行展示，后台我们使用Spring Cloud和Spring Boot来作为我们的核心框架，由于Spring Boot支持Thymeleaf作为页面引擎，因此我们的页面引擎不再使用JSP，同时利用docker作为虚拟化技术来进行搭建各种基础设施，以及服务的部署，使用gitlab来实现持续集成，做到开发人员提交了新代码之后，立刻进行构建、（单元）测试。具体业务的开发将不再是我们研究的重点。
下面通过部分具有代表性的功能模块进行具体详解，以及介绍所用到的技术实现： 3.1基础设施即服务-Doeker
Docker是一个开源的应用容器引擎，开发者可以将自己的应用打包放到一个可移植的镜像中，然后发布到任何装有Docker的电脑上，一个虚拟机可同时拥有若干的docker容器，各个容器之间是完全地隔离。真正做到一次上传，到处运行。
Docker官方为了简化流程我们在系统上只需运行一行代码即可下载，由于国内拉取镜像会有些困难，我们可以设置使用阿里云的加速器，在修改成功后可以测试是否有效，使用docker需要学会docker的基本命令，只有熟悉使用docker才能进行基础设施的搭建。同时为了解决多个docker容器一次部署完成我们使用Docker Compose来进行快速的部署分布式应用。
3.2平台即服务-Nexus，GitLab，Registry
我们利用Docker来作为基础设施，安装Nexus，GitLab，Registry作为我们微服务私有云平台的支撑，Nexus是一个强大的仓库管理平台，会收入我们的JAR包，在安装Nexus后我们需要在项目的pom文件中加入我们Nexus的地址。GitLab是一个开源的分布式版本控制系统，类似于GitHub，但是GitLab是私有云平台，我们在后期的持续集成中也会使用Git-Lab作为支撑，同样我们在Docker中拉取镜像来运行一个GitLab容器，在安装完成后，进行登录，配置SSH免密登录后，我们便可以创建项目并将我们的项目上传到GitLab平台中。Registry是一个私有的上传镜像的平台，同样通过Docker来进行安装。
3.3平台即服务-Spring Cloud基础设施搭建
Spring Cloud为开发人员提供了快速构建分布式系统中一些常见模式的工具f例如配置管理，服务发现，断路器，智能路由，微代理，控制总线）。微服务中由于服务的众多，我们需要有一个专门的组件来发现这些服务，因此我们采用Eureka作为我们的服务注册与发现中心。在微服务中，由于大量的服务，也产生新的问题，那就是网络的不可靠性，因此Spring Cloud中使用熔断器模式Hystrix来解决这个问题，在某个服务出现问题后，为了避免连锁反应，可以通过fallback方法返回一个固定值。我们使用Spring Cloud提供的Zuul作为路由转发和过滤器，路由功能是微服务的一部分，比如/api/user转发到到User服务。使用Spring Cloud ZipKin作为分布式链路追踪，为了解决服务之间的复杂调用问题。使用SpringCloud Con-fig作为系统的配置中心，每个服务从这里获取自身配置所需要的参数。使用Spring Boot Admin用于管理和监控一个或多个SpringBoot程序。均在docker容器中部署，作为微服务的基础设施。
3.4GitLab实现持续集成
正如前文所讲，我们需要部署几十个甚至成百上千个服务，如果我们每次都手动打包，手动测试，耗费的时间将是无可估量的，因此我們必须采用持续集成来部署服务，首先我们要安装GitLab Runner来进行cI，安装完成后我们启动Runner，然后和GitLab cI进行绑定，绑定完成后可以在GitLab的私有平台的设置CI/CD中进行查看，我们需要在项目中编写.gitlab-ci.yml文件即可进行持续集成。
4结论
通过对微服务架构的电商平台进行研究，其主要是通过将功能分解到各个离散的服务中以实现对解决方案的解耦，单一职责，模块之间分而治之。相对于传统的单体应用开发，微服务架构使得产品的变成一颗颗小的微粒，这些微粒组成一个系统，单个服务启动时间较短，同样因为各个服务之间通过API的方式通讯，所以无论是什么编程语言只要能通过API进行通讯即可，因此技术栈不受限制，同时微服务与云原生以及DevO-ps能够很好地结合，使得开发更加优雅、便捷。然而软件开发没有银弹，分布式系统的cAP理论已经证明了分布式系统所存在的固有问题，同样因为服务众多，网络的不可靠性也是我们需要注意的焦点，起点高，涉及的知识广泛，团队如何进行敏捷开发也是未来微服务架构所面临的挑战。
转载注明来源:https://www.xzbu.com/8/view-15237943.htm
