研发文档02新项目技术v120307.docx

研发文档02新项目技术v120307.docx

《研发文档02新项目技术v120307.docx》由会员分享，可在线阅读，更多相关《研发文档02新项目技术v120307.docx（21页珍藏版）》请在冰点文库上搜索。

研发文档02新项目技术v120307

后台技术说明

1.技术概述

本着较好的支撑业务需求、采用稳键的策略，只选主流开发技术的理念进行选择：

运行平台

Centos7.x（默认），原则上也支持windows系统部署

虚拟化

Kvm,后续docker、k8s、公有云部署

数据库部

postgresql、mysql等，要支持跨数据库部署

开发语言

Java8.x,采用阿里巴巴Java编码规范

后台开发框架

SpringBoot2+Mybatisplus

微服务技术

SpringcloudGreenwich,Springcloudalibaba

Springcloudgateway+Nacos+dobbo+Sentinel

缓存技术

redis

前端技术

Yarn+vue+Element-UI

Mybatisplus支持跨多种数据库：

支持MySQL、MariaDB、Oracle、DB2、H2、HSQL、SQLite、Postgre、SQLServer、等多种数据库，在国内的项目中有广泛的使用。

但缺点是跨数据库能力较弱，有可能需要针对不同数据库做适配置。

如果要完全做到跨数据库，适配每种数据库的方言，可以考虑使用JPA,hibernate这样的技术。

2.Web前端

2.1.概述

采用前后端完全分离的方式。

前端技术上，采用了vue+Element-UI+yarn的组合。

2.2.前端技术

2.2.1.开发工具

Vscode

2.3.前后端完全分离的特点

1）前端JS可以做很大部分的数据处理工作，分担了服务器的很多压力。

2）后台错误不会直接反映到前台。

3）数据和模板在浏览器中合成可展示的html，减少网络IO。

4）便于调试错误。

5）开发人员分工更加明确。

6）便于对静态资源的缓存和独立部署。

3.后端技术

3.1.后端业务架构图

3.2.中间件使用

3.2.1.中间件标准化

Centos安装,默认要提供一个非root用户

一般情况下，不要关闭系统防火墙，尤其是具有外网IP的机器。

Tomcat等Java服务器,不要修改为1024以下的端口。

也不要以root用户启动。

环境安装软件的版本，配置，启动方式标准化，模式化，文档化。

Linux（Centos）

Mysql

Java

Tomcat

Nginx

Redis

应该先找现成的软件仓库，如果没有，想办法下载rpm（或deb）软件包，一般不建议从源代码方式安装。

配置中隐藏nginx标记、tomcat标记。

必须设置好开机启动。

再使用虚拟化技术或者容器技术，使之便于迁移、快速部署。

所有的Java程序,前端均应进行nginx代理。

以方式做负载均衡。

3.2.2.反向代理

3.2.2.1.传输安全

全站只支持HTTPS协议，允许协议升级到HTTP2.0。

服务的入口上nginx配置。

3.2.3.分布式缓存

3.2.4.消息队列

3.2.4.1.应用场景

1）异步处理

2）应用解耦

3）流量削峰

4）消息通讯

3.2.4.2.rabbitMQ

 RabbitMQ是一个由erlang开发的AMQP的开源实现。

在项目中，将一些无需即时返回且耗时的操作提取出来，进行了异步处理，而这种异步处理的方式大大的节省了服务器的请求响应时间，从而提高了系统的吞吐量。

3.2.5.日志系统

ELK由ElasticSearch、Logstash和Kiabana三个开源工具组成。

日志主要包括系统日志、应用程序日志和安全日志。

日志被分散的储存不同的设备上，集中化管理日志后，可以对日志进行统计和检索。

3.3.开发架构

3.3.1.若干基本原则

3.3.1.1.幂等性原则

幂等性的数学表达：

f（f（x））=f（x）。

幂等性是系统接口对外的一种承诺。

就是用户对于同一操作发起的一次请求或者多次请求的结果是一致的，不会因为多次请求而产生了副作用。

那么这个请求方法就被认为具有幂等性。

在分布式环境下各个服务之间调用用,也应该尽可能提供幂等性接口，则正确处理重复请求，易于排错，易于维护。

3.3.1.1.1.若干关注重点

幂等不仅仅只是一次（或多次）请求对资源没有副作用（比如查询数据库操作，没有增删改，因此没有对数据库有任何影响）。

幂等还包括第一次请求的时候对资源产生了副作用，但是以后的多次请求都不会再对资源产生副作用。

幂等关注的是以后的多次请求是否对资源产生的副作用，而不关注结果。

网络超时等问题，不是幂等的讨论范围。

3.3.1.1.2.幂等性的必要性

幂等可以使得客户端逻辑处理变得简单，但是却以服务逻辑变得复杂为代价。

满足幂等服务的需要在逻辑中至少包含两点：

首先去查询上一次的执行状态，如果没有则认为是第一次请求

在服务改变状态的业务逻辑前，保证防重复提交的逻辑

3.3.1.1.3.幂等性反例

幂等性接口的一个反面情况是刷数据库：

查询数据的请求中，夹杂着对数据的修改操作。

同一修改请求重复执行时，都会增加若干条数据或者都会把相应的数据修改一次。

同一删除操作的请求重复执行时,都会删除若干条数据。

在请求设计时要慎重考虑。

3.3.1.1.4.幂等性的不足

幂等是为了简化客户端逻辑处理，却增加了服务提供者的逻辑和成本，是否有必要，需要根据具体场景具体分析，因此除了业务上的特殊要求外，尽量不提供幂等的接口。

增加了额外控制幂等的业务逻辑，复杂化了业务功能；

把并行执行的功能改为串行执行，降低了执行效率。

3.3.1.1.5.保证幂等策略

幂等需要通过唯一的业务单号来保证。

也就是说相同的业务单号，认为是同一笔业务。

使用这个唯一的业务单号来确保，后面多次的相同的业务单号的处理逻辑和执行效果是一致的。

下面以支付为例，在不考虑并发的情况下，实现幂等很简单：

①先查询一下订单是否已经支付过，②如果已经支付过，则返回支付成功；如果没有支付，进行支付流程，修改订单状态为‘已支付’。

3.3.1.1.5.1.防重复提交策略

上述的保证幂等方案是分成两步的，第②步依赖第①步的查询结果，无法保证原子性的。

在高并发下就会出现下面的情况：

第二次请求在第一次请求第②步订单状态还没有修改为‘已支付状态’的情况下到来。

既然得出了这个结论，余下的问题也就变得简单：

把查询和变更状态操作加锁，将并行操作改为串行操作。

3.3.1.1.5.2.乐观锁

如果只是更新已有的数据，没有必要对业务进行加锁，设计表结构时使用乐观锁，一般通过version来做乐观锁，这样既能保证执行效率，又能保证幂等。

例如：

UPDATEtab1SETcol1=1,version=version+1WHEREversion=#version#不过，乐观锁存在失效的情况，就是常说的ABA问题，不过如果version版本一直是自增的就不会出现ABA的情况。

（从网上找了一张图片很能说明乐观锁，引用过来，出自Mybatis对乐观锁的支持）

防重表

使用订单号orderNo做为去重表的唯一索引，每次请求都根据订单号向去重表中插入一条数据。

第一次请求查询订单支付状态，当然订单没有支付，进行支付操作，无论成功与否，执行完后更新订单状态为成功或失败，删除去重表中的数据。

后续的订单因为表中唯一索引而插入失败，则返回操作失败，直到第一次的请求完成（成功或失败）。

可以看出防重表作用是加锁的功能。

3.3.1.1.5.3.分布式锁

这里使用的防重表可以使用分布式锁代替，比如Redis。

订单发起支付请求，支付系统会去Redis缓存中查询是否存在该订单号的Key，如果不存在，则向Redis增加Key为订单号。

查询订单支付已经支付，如果没有则进行支付，支付完成后删除该订单号的Key。

通过Redis做到了分布式锁，只有这次订单订单支付请求完成，下次请求才能进来。

相比去重表，将放并发做到了缓存中，较为高效。

思路相同，同一时间只能完成一次支付请求。

3.3.1.1.5.4.token令牌

这种方式分成两个阶段：

申请token阶段和支付阶段。

第一阶段，在进入到提交订单页面之前，需要订单系统根据用户信息向支付系统发起一次申请token的请求，支付系统将token保存到Redis缓存中，为第二阶段支付使用。

第二阶段，订单系统拿着申请到的token发起支付请求，支付系统会检查Redis中是否存在该token，如果存在，表示第一次发起支付请求，删除缓存中token后开始支付逻辑处理；如果缓存中不存在，表示非法请求。

实际上这里的token是一个信物，支付系统根据token确认，你是你妈的孩子。

不足是需要系统间交互两次，流程较上述方法复杂。

3.3.1.1.5.5.支付缓冲区

把订单的支付请求都快速地接下来，一个快速接单的缓冲管道。

后续使用异步任务处理管道中的数据，过滤掉重复的待支付订单。

优点是同步转异步，高吞吐。

不足是不能及时地返回支付结果，需要后续监听支付结果的异步返回。

3.3.1.1.6.电商常见问题

3.3.1.1.6.1.如何防范POST重复提交

HTTPPOST操作既不是安全的，也不是幂等的（至少在HTTP规范里没有保证）。

当我们因为反复刷新浏览器导致多次提交表单，多次发出同样的POST请求，导致远端服务器重复创建出了资源。

所以，对于电商应用来说，第一对应的后端WebService一定要做到幂等性，第二服务器端收到POST请求，在操作成功后必须302跳转到另外一个页面，这样即使用户刷新页面，也不会重复提交表单。

2.2.集群环境下的定时任务幂等性

分布式环境下，定时任务或异步处理如何保持幂等性？

3.3.1.1.6.2.分布式事务和幂等性

把分布式事务分解为具有幂等性的异步消息处理：

电商的很多业务，考虑更多的是BASE（即BasicallyAvailable、Softstate、和Eventuallyconsistent），而不是ACID（Atomicity、Consistency、Isolation和Durability）。

即为了满足高负载的用户访问，我们可以容忍短暂的数据不一致。

那怎么做呢？

第一，不做分布式事务，代价太大。

第二，不一定需要实时一致性，只需要保证最终的一致性即可。

第三，“通过状态机和严格的有序操作，来最大限度地降低不一致性”。

第四，最终一致性（EventuallyConsistent）通过异步事件做到。

如果消息具有操作幂等性，也就是一个消息被应用多次与应用一次产生的效果是一样的话，那么把不需要同步执行的事务交给异步消息推送和订阅者集群来处理即可。

假如消息处理失败，那么就消息重播，由于幂等性，应用多次也能产生正确的结果。

实际情况下，消息很难具有幂等性，解决方法是使用另一个表记录已经被成功应用的消息，即消息队列和消息应用状态表一起来解决问题。

参考资源：

2）相关设计模式“SynchronizedToken（简而言之，就是客户端的每一次Request里，必须携带一个服务器端给出的HashCode作为Token，这个Token只能用一次，不能重复使用）”和“幂等接收器，IdempotentReceiver”；

3）针对POST，请参考HTTPLR（由BilldehÓra提出）、MarkNottingham的POE（POSTOnceExactly）和PaulPrescod的HTTP中的可靠传递。

（另一个值得一提的是YaronGoland的SOA-Rity）；

4）淘宝核心系统团队博客，2010，用消息队列和消息应用状态表来消除分布式事务

3.3.1.2.无状态特性

HTTP是一种不保存状态，无状态（stateless）协议。

HTTP协议自身不对请求和响应之间的通信状态进行保存。

也就是说在HTTP这个级别，协议对于发送过的请求或响应都不做持久化处理。

协议本身并不保留之前一切的请求或响应报文的信息。

这是为了更快地处理大量事务，确保协议的可伸缩性，而特意把HTTP协议设计成如此简单的。

3.3.1.3.RESTAPI接口

对外接口一般都是http接口，应该根据Http方法的语义来发放请求。

对于资源的具体操作类型，由HTTP动词表示。

常用的HTTP动词有下面五个（括号里是对应的SQL命令）。

GET（SELECT）：

从服务器取出资源（一项或多项）。

POST（CREATE）：

在服务器新建一个资源。

PUT（UPDATE）：

在服务器更新资源（客户端提供改变后的完整资源）。

PATCH（UPDATE）：

在服务器更新资源（客户端提供改变的属性）。

DELETE（DELETE）：

从服务器删除资源。

GET方法

GET方法是向服务器查询，是对服务器的读操作，不会对系统产生副作用，具有幂等性（不代表每次请求都是相同的结果）

PUT方法

也就是说PUT方法首先判断系统中是否有相关的记录，如果有记录则更新该记录，如果没有则新增记录。

3.3.2.功能模块化

模块化是对程序业务的纵向分解，使得程序可以集中化部署、或者按模块组合部署。

3.3.2.1.开发分层图

图中默认上层依赖于下层，箭头关系表示可直接依赖，如：

开放接口层可以依赖于Web层，也可以直接依赖于Service层，依此类推：

3.3.2.2.分层功能说明和界定

1.开放接口层：

可直接封装Service方法暴露成RPC接口；通过Web封装成http接口；进行网关安全控制、流量控制等。

2.终端显示层：

各个端的模板渲染并执行显示的层。

当前主要是Freemarker渲染，JS渲染，JSP渲染，移动端展示等。

3.Web层：

主要是对访问控制进行转发，各类基本参数校验，或者不复用的业务简单处理等。

4.Service层：

相对具体的业务逻辑服务层。

5.Manager层：

通用业务处理层，它有如下特征：

1）对第三方平台封装的层，预处理返回结果及转化异常信息；

2）对Service层通用能力的下沉，如缓存方案、中间件通用处理；

3）与DAO层交互，对多个DAO的组合复用。

6.DAO层：

数据访问层，封装所有的SQL语句，与底层MySQL、Oracle、Hbase进行数据交互。

7.外部接口或第三方平台：

包括其它部门RPC开放接口，基础平台，其它公司的HTTP接口。

3.3.3.配置管理

https:

//nacos.io/zh-cn/

一个更易于构建云原生应用的动态服务发现、配置管理和服务管理平台。

1.动态配置服务

2.服务发现及管理

3.动态DNS服务

3.3.3.1.域名配置

在程序中或配置文件中，做到只使用域名，可以自定义本地域名。

不使用IP.

优点

1.对开发人员来说，提交文件时少了一些困扰。

2.对运维友好， 运维在也不需要动war 包里的东西。

3. 在不同环境部署时，不需对war做任何改动。

4.依赖服务的ip有变， 只需改hosts文件。

5.在hosts里一改， 实时生效。

6.更新符合“约定优于配置”的理念。

3.3.4.APIgateway

3.3.4.1.对外授权

对外授权统一采同OpenIDConnect技术。

OpenIDConnect（目前版本是1.0）是OAuth2.0协议（可参考本人此篇：

OAuth2.0/RCF6749协议解读）之上的简单身份层，用API进行身份交互的框架，允许客户端根据授权服务器的认证结果最终确认用户的身份，以及获取基本的用户信息；它支持包括Web、移动、JavaScript在内的所有客户端类型；它是可扩展的协议，允许你使用某些可选功能，如身份数据加密、OpenID提供商发现、会话管理。

KeyCloak

https:

//www.keycloak.org/

CAS+OAuth

https:

//apereo.github.io/cas/5.2.x/installation/OAuth-OpenId-Authentication.html

https:

//apereo.github.io/cas/5.2.x/installation/OIDC-Authentication.html

3.3.4.2.其它应用切面服务

反向路由，安全验证，限流等、对读请求增加缓存机制。

3.3.5.RPC和服务治理

3.3.5.1.rpc和服务治理初衷

1、服务耦合问题。

2、不同团除服务依赖问题。

3、服务提供者问题。

以前你要模块间调用是要写服务提供者的ip，现在不用管服务提供者的位置，只写注册中心的ip。

4、多语言调用问题

5、过多的服务URL配置困难

6、服务消费者和提供者累计调用次数和调用时间

等等问题和需求，使得采用rpc和服务治理非常必要。

3.3.6.技术选型

3.3.6.1.注册中心和配置中心

Nacos

3.3.6.2.API网关

3.3.6.3.Rpc框架

Dubbo在国内非常有影响力的一个rpc框架。

目前是在apache开源的alibaba产品，同时也是Springcloudalibaba的开源的关键组成部分。

3.3.6.3.1.dubbo架构

3.3.6.3.1.1.节点角色说明

节点

角色说明

Provider

暴露服务的服务提供方

Consumer

调用远程服务的服务消费方

Registry

服务注册与发现的注册中心

Monitor

统计服务的调用次数和调用时间的监控中心

Container

服务运行容器

3.3.6.3.1.2.调用关系说明

1.服务容器负责启动，加载，运行服务提供者。

2.服务提供者在启动时，向注册中心注册自己提供的服务。

3.服务消费者在启动时，向注册中心订阅自己所需的服务。

4.注册中心返回服务提供者地址列表给消费者，如果有变更，注册中心将基于长连接推送变更数据给消费者。

5.服务消费者，从提供者地址列表中，基于软负载均衡算法，选一台提供者进行调用，如果调用失败，再选另一台调用。

6.服务消费者和提供者，在内存中累计调用次数和调用时间，定时每分钟发送一次统计数据到监控中心。

Dubbo架构具有以下几个特点，分别是连通性、健壮性、伸缩性、以及向未来架构的升级性。

3.4.开发框架

3.4.1.开发框架概述

根据公司目前情况和人员的技术特点，现制订以下开发框架要求：

1、基于Servlet3.1。

2、总体上说采用Java8+Tomcat8.5.x+Springboot+Mybatis+Maven方式+json+前端。

3.4.2.Java8介绍

Java8应该来说，对Java平台进行了大量的更新和功能增加。

详情见:

若干常用JAVA新特性

1）接口中可以写默认方法

2）Lambda表达式、

3）DateAPI

4）Annotation注解

5）标准化Base64API

6）串行和并行Stream

7）新一代的javascript引擎Nashorn，jjs工具和javax.scriptAPI

8）ParallelArraySorting

9）NewDate&TimeAPI

JVM新特性

1）移除了永久代（PermGen），变成了Metaspace。

2）G1GC可以用于大内存的生产环境。

从JDK8开始，永久代（PermGen）的概念被废弃掉了，取而代之的是一个称为Metaspace的存储空间。

Metaspace使用的是本地内存，而不是堆内存，也就是说在默认情况下Metaspace的大小只与本地内存大小有关。

3.4.3.常用工具库

用好工具库，不再重新发明轮子！

在Java社区广泛使用的工具类：

3.4.3.1.Jdk

3.4.3.2.apacheCommons

http:

//commons.apache.org/

∙TheCommonsProper-ArepositoryofreusableJavacomponents.

∙TheCommonsSandbox-AworkspaceforJavacomponentdevelopment.

3.4.3.3.GoogleGuava

Guava是一组核心库，包括新的集合类型（例如multimap和multiset），不可变集合，图形库，函数类型，内存缓存以及用于并发，I/O，散列，基本类型操作，反射，字符串处理等等的工具类。

3.4.4.Maven介绍

采用Maven做为项目构建工具。

下面介绍一个一般开发者了解的比较少的一个Maven特性。

大家都知道gradle构建工具支持Groovy语言描述构建过程。

但maven支持非常多的语言来描述构建过程。

这就是maven-polyglot。

Mavenpom.xml文件，一般是XML，Polyglot是Maven3.3.1+之后支持的一个扩展。

可以支持Atom、Groovy、Clojure、Ruby、Scala、YAML编写pom.xml文件。

3.4.5.Springboot

3.4.5.1.Spring开发事项

1.Springxsd忽略版本号

忽略XSD的版本号优点

因为如果没有配置版本号，取的就是当前jar里的XSD文件，减少了各种风险。

而且这样约定大于配置的方式很优雅。

3.4.5.2.Springboot特点

SpringBoot的主要优点：

1）为所有Spring开发者更快的入门

2）开箱即用，提供各种默认配置来简化项目配置，真正的实现了约定优于配置的理念。

3）内嵌式容器,支持Tomcat、Jetty、UnderTow,简化了Web项目。

4）没有冗余代码生成和XML配置的要求

5）更加方便做单元测试，Javamain方法方式。

6）新的Web框架WebFlux，以支持Reactive式编程。

7）四大组件auto-configuration、starters、cli、actuator。

3.4.5.3.和Spring关系

Spring系列的技术，是框架，是工具；Springboot则是伴随着Spring4的产生而产生的，同时是建立在Spring4之上，为开发者提供的一套解决方案和可参照的Spring的最佳开发实践。

3.4.5.4.Springboot运行模式

3.4.5.4.1.FatJarMode

FatJar就