• 关于

    重复请求如何看配置

    的搜索结果

回答

生命周期:加载和实例化Servlet我们来看一下Tomcat是如何加载的: 1. 如果已配置自动装入选项,则在启动时自动载入。 2. 在服务器启动时,客户机首次向Servlet发出请求。 3. 重新装入Servlet时。 当启动Servlet容器时,容器首先查找一个配置文件web.xml,这个文件中记录了可以提供服务的Servlet。每个Servlet被指定一个Servlet名,也就是这个Servlet实际对应的Java的完整class文件名。Servlet容器会为每个自动装入选项的Servlet创建一个实例。所以,每个Servlet类必须有一个公共的无参数的构造器。 初始化 当Servlet被实例化后,Servlet容器将调用每个Servlet的init方法来实例化每个实例,执行完init方法之后,Servlet处于“已初始化”状态。所以说,一旦Servlet被实例化,那么必将调用init方法。通过Servlet在启动后不立即初始化,而是收到请求后进行。在web.xml文件中用<load-on-statup> ...... </load-on-statup>对Servlet进行预先初始化。 初始化失败后,执行init()方法抛出ServletException异常,Servlet对象将会被垃圾回收器回收,当客户端第一次访问服务器时加载Servlet实现类,创建对象并执行初始化方法。 请求处理 Servlet 被初始化以后,就处于能响应请求的就绪状态。每个对Servlet 的请求由一个Servlet Request 对象代表。Servlet 给客户端的响应由一个Servlet Response对象代表。对于到达客户机的请求,服务器创建特定于请求的一个“请求”对象和一个“响应”对象。调用service方法,这个方法可以调用其他方法来处理请求。 Service方法会在服务器被访问时调用,Servlet对象的生命周期中service方法可能被多次调用,由于web-server启动后,服务器中公开的部分资源将处于网络中,当网络中的不同主机(客户端)并发访问服务器中的同一资源,服务器将开设多个线程处理不同的请求,多线程同时处理同一对象时,有可能出现数据并发访问的错误。 另外注意,多线程难免同时处理同一变量时(如:对同一文件进行写操作),且有读写操作时,必须考虑是否加上同步,同步添加时,不要添加范围过大,有可能使程序变为纯粹的单线程,大大削弱了系统性能;只需要做到多个线程安全的访问相同的对象就可以了。 卸载Servlet 当服务器不再需要Servlet实例或重新装入时,会调用destroy方法,使用这个方法,Servlet可以释放掉所有在init方法申请的资源。一个Servlet实例一旦终止,就不允许再次被调用,只能等待被卸载。 Servlet一旦终止,Servlet实例即可被垃圾回收,处于“卸载”状态,如果Servlet容器被关闭,Servlet也会被卸载,一个Servlet实例只能初始化一次,但可以创建多个相同的Servlet实例。如相同的Servlet可以在根据不同的配置参数连接不同的数据库时创建多个实例。 各个方法:init()方法 在Servlet的生命周期中,仅执行一次init()方法,它是在服务器装入Servlet时执行的,可以配置服务器,以在启动服务器或客户机首次访问Servlet时装入Servlet。无论有多少客户机访问Servlet,都不会重复执行init(); service()方法 它是Servlet的核心,每当一个客户请求一个HttpServlet对象,该对象的Service()方法就要调用,而且传递给这个方法一个“请求”(ServletRequest)对象和一个“响应”(ServletResponse)对象作为参数。在HttpServlet中已存在Service()方法。默认的服务功能是调用与HTTP请求的方法相应的do功能。 destroy()方法 仅执行一次,在服务器端停止且卸载Servlet时执行该方法,有点类似于C++的delete方法。一个Servlet在运行service()方法时可能会产生其他的线程,因此需要确认在调用destroy()方法时,这些线程已经终止或完成。 下面来谈谈Servlet的生命周期,Servlet的生命周期是由Servlet容器来控制的,它始于装入Web服务器的内存时,并在终止或重新装入Servlet时结束。这项操作一般是动态执行的。然而,Server通常会提供一个管理的选项,用于在Server启动时强制装载和初始化特定的Servlet。 在代码中,Servlet生命周期由接口javax.servlet.Servlet定义。所有的Java Servlet 必须直接或间接地实现javax.servlet.Servlet接口,这样才能在Servlet Engine上运行。javax.servlet.Servlet接口定义了一些方法,在Servlet 的生命周期中,这些方法会在特定时间按照一定的顺序被调用。

小川游鱼 2019-12-02 01:50:40 0 浏览量 回答数 0

问题

zookeeper 都有哪些使用场景?【Java问答学堂】56期

剑曼红尘 2020-07-13 21:37:59 75 浏览量 回答数 1

问题

Nginx性能为什么如此吊

小柒2012 2019-12-01 21:20:47 15038 浏览量 回答数 3

阿里云试用中心,为您提供0门槛上云实践机会!

0元试用32+款产品,最高免费12个月!拨打95187-1,咨询专业上云建议!

问题

程序员报错QA大分享(1)

问问小秘 2020-06-18 15:46:14 8 浏览量 回答数 1

问题

网站优化之提升访问速度的影响因素

chenchuan 2019-12-01 21:01:05 7177 浏览量 回答数 0

问题

应该如何使用阿里云-第二版 持续更新中

rippletek 2019-12-01 22:07:09 9256 浏览量 回答数 1

问题

应该如何使用阿里云-第二版 持续更新中

rippletek 2019-12-01 22:01:53 7661 浏览量 回答数 4

问题

dubbo 负载均衡策略和集群容错策略都有哪些?动态代理策略呢?【Java问答学堂】49期

剑曼红尘 2020-07-02 17:35:03 17 浏览量 回答数 1

问题

网站优化之提升访问速度的影响因素

chenchuan 2019-12-01 21:37:28 3707 浏览量 回答数 0

问题

dubbo 的 spi 思想是什么?【Java问答学堂】50期

剑曼红尘 2020-07-07 09:48:29 25 浏览量 回答数 1

回答

00根本不大,没有达到tomcat的极限的,所以看你业务的。。业务代码有问题,50个不也照样跑满么######的确,代码问题。######一台tomcat 通常分配500个请求的,你可以用nginx 做代理转发,后端起多个tomcat######回复 @-Jacen- : 我测试出来windows 下没很大差别######昨天问了一个朋友,说windows下apache比nginx性能高。是这样吗?######超时时间太长了,你这样直接就把服务器拖死了######你说的超时时间是指connectionTimeout 还是keepAliveTimeout###### 如何定义高并发? 上线前酝酿一下最高的并发请求数,针对请求数做2/8法则, 压力测试单台容器能支撑多久... 最后建议搞集群把...分担压力. ######nginx在前面,毕竟tomcat并不是为大并发设计的!还有,你的每个请求运行逻辑不要太复杂,不要占用过长时间######500台手机在线,真正的并发约为20-40%之间,一台tomcat完全可以抗的住,修改tomcat的连接数同时看下OS的文件打开数限制,另外开始压缩,最好前面用nginx反向代理######回复 @Eric_林 : 嗯,都不熟悉,到处乱搞。######回复 @-Jacen- : 都差不多,看你哪个更熟悉######windows作为服务器,用apache还是nginx更好?######你这一个processTime  这么久? 最长的半个小时,一台tomcat   请求多了 你不挂 谁挂 ######回复 @-Jacen- : 悲观锁:一旦你数据库处理稍微久 并发量上来 会导致链接不够用,然后任务被拒绝。 乐观锁:会导致很多无效的mysql操作,同样会消耗很多资源。 所以要具体业务场景及根据系统可预想的并发量进行具体分析,一种比较好的方式是用redis协助来做乐观锁,还有一种就是redis的原子性操作是一种更好的方式,再或者用redis的lua方式。反正就是具体业务要具体分析,哈哈哈哈哈######回复 @Ambitor : 为了防止多线程重复都数据库,加了个synchronized锁,结果一段时间就挂了,后来去掉,就好了。现在有个思路通过数据库悲观锁或者乐观锁解决。######回复 @-Jacen- : 还有如果你都是长连接的话,那你可能就要用集群了######回复 @-Jacen- : 我觉得线程5000个是多了,然后空闲存活时间只有60秒。但是JDK的线程池的创建策略是任务队列排不下了再新建线程的,所以如果你的应用规模没达到每秒上百的并发(注意,我说的是并发,不是同时在线) 应该不是问题,所以这个地方问题 应该是你的业务逻辑代码有问题?仔细研究下你们代码是不是有某些问题?不然一个请求怎么这么久。######就是不清楚为啥这个time会这么久。求指点######你搞这么大的线程,线程切换估计都浪费很多cpu了######负载均衡呢######建议前面加nginx( 配置比apache简单),后面改成多个tomcat。

kun坤 2020-06-14 15:40:34 0 浏览量 回答数 0

回答

500根本不大,没有达到tomcat的极限的,所以看你业务的。。业务代码有问题,50个不也照样跑满么######的确,代码问题。######一台tomcat 通常分配500个请求的,你可以用nginx 做代理转发,后端起多个tomcat######回复 @-Jacen- : 我测试出来windows 下没很大差别######昨天问了一个朋友,说windows下apache比nginx性能高。是这样吗?######超时时间太长了,你这样直接就把服务器拖死了######你说的超时时间是指connectionTimeout 还是keepAliveTimeout###### 如何定义高并发? 上线前酝酿一下最高的并发请求数,针对请求数做2/8法则, 压力测试单台容器能支撑多久... 最后建议搞集群把...分担压力. ######nginx在前面,毕竟tomcat并不是为大并发设计的!还有,你的每个请求运行逻辑不要太复杂,不要占用过长时间######500台手机在线,真正的并发约为20-40%之间,一台tomcat完全可以抗的住,修改tomcat的连接数同时看下OS的文件打开数限制,另外开始压缩,最好前面用nginx反向代理######回复 @Eric_林 : 嗯,都不熟悉,到处乱搞。######回复 @-Jacen- : 都差不多,看你哪个更熟悉######windows作为服务器,用apache还是nginx更好?######你这一个processTime  这么久? 最长的半个小时,一台tomcat   请求多了 你不挂 谁挂 ######回复 @-Jacen- : 悲观锁:一旦你数据库处理稍微久 并发量上来 会导致链接不够用,然后任务被拒绝。 乐观锁:会导致很多无效的mysql操作,同样会消耗很多资源。 所以要具体业务场景及根据系统可预想的并发量进行具体分析,一种比较好的方式是用redis协助来做乐观锁,还有一种就是redis的原子性操作是一种更好的方式,再或者用redis的lua方式。反正就是具体业务要具体分析,哈哈哈哈哈######回复 @Ambitor : 为了防止多线程重复都数据库,加了个synchronized锁,结果一段时间就挂了,后来去掉,就好了。现在有个思路通过数据库悲观锁或者乐观锁解决。######回复 @-Jacen- : 还有如果你都是长连接的话,那你可能就要用集群了######回复 @-Jacen- : 我觉得线程5000个是多了,然后空闲存活时间只有60秒。但是JDK的线程池的创建策略是任务队列排不下了再新建线程的,所以如果你的应用规模没达到每秒上百的并发(注意,我说的是并发,不是同时在线) 应该不是问题,所以这个地方问题 应该是你的业务逻辑代码有问题?仔细研究下你们代码是不是有某些问题?不然一个请求怎么这么久。######就是不清楚为啥这个time会这么久。求指点######你搞这么大的线程,线程切换估计都浪费很多cpu了######负载均衡呢######建议前面加nginx( 配置比apache简单),后面改成多个tomcat。

kun坤 2020-06-02 15:01:27 0 浏览量 回答数 0

回答

微服务 (MicroServices) 架构是当前互联网业界的一个技术热点,圈里有不少同行朋友当前有计划在各自公司开展微服务化体系建设,他们都有相同的疑问:一个微服务架构有哪些技术关注点 (technical concerns)?需要哪些基础框架或组件来支持微服务架构?这些框架或组件该如何选型?笔者之前在两家大型互联网公司参与和主导过大型服务化体系和框架建设,同时在这块也投入了很多时间去学习和研究,有一些经验和学习心得,可以和大家一起分享。 服务注册、发现、负载均衡和健康检查和单块 (Monolithic) 架构不同,微服务架构是由一系列职责单一的细粒度服务构成的分布式网状结构,服务之间通过轻量机制进行通信,这时候必然引入一个服务注册发现问题,也就是说服务提供方要注册通告服务地址,服务的调用方要能发现目标服务,同时服务提供方一般以集群方式提供服务,也就引入了负载均衡和健康检查问题。根据负载均衡 LB 所在位置的不同,目前主要的服务注册、发现和负载均衡方案有三种: 第一种是集中式 LB 方案,如下图 Fig 1,在服务消费者和服务提供者之间有一个独立的 LB,LB 通常是专门的硬件设备如 F5,或者基于软件如 LVS,HAproxy 等实现。LB 上有所有服务的地址映射表,通常由运维配置注册,当服务消费方调用某个目标服务时,它向 LB 发起请求,由 LB 以某种策略(比如 Round-Robin)做负载均衡后将请求转发到目标服务。LB 一般具备健康检查能力,能自动摘除不健康的服务实例。服务消费方如何发现 LB 呢?通常的做法是通过 DNS,运维人员为服务配置一个 DNS 域名,这个域名指向 LB。 Fig 1, 集中式 LB 方案 集中式 LB 方案实现简单,在 LB 上也容易做集中式的访问控制,这一方案目前还是业界主流。集中式 LB 的主要问题是单点问题,所有服务调用流量都经过 LB,当服务数量和调用量大的时候,LB 容易成为瓶颈,且一旦 LB 发生故障对整个系统的影响是灾难性的。另外,LB 在服务消费方和服务提供方之间增加了一跳 (hop),有一定性能开销。 第二种是进程内 LB 方案,针对集中式 LB 的不足,进程内 LB 方案将 LB 的功能以库的形式集成到服务消费方进程里头,该方案也被称为软负载 (Soft Load Balancing) 或者客户端负载方案,下图 Fig 2 展示了这种方案的工作原理。这一方案需要一个服务注册表 (Service Registry) 配合支持服务自注册和自发现,服务提供方启动时,首先将服务地址注册到服务注册表(同时定期报心跳到服务注册表以表明服务的存活状态,相当于健康检查),服务消费方要访问某个服务时,它通过内置的 LB 组件向服务注册表查询(同时缓存并定期刷新)目标服务地址列表,然后以某种负载均衡策略选择一个目标服务地址,最后向目标服务发起请求。这一方案对服务注册表的可用性 (Availability) 要求很高,一般采用能满足高可用分布式一致的组件(例如 Zookeeper, Consul, Etcd 等)来实现。 Fig 2, 进程内 LB 方案 进程内 LB 方案是一种分布式方案,LB 和服务发现能力被分散到每一个服务消费者的进程内部,同时服务消费方和服务提供方之间是直接调用,没有额外开销,性能比较好。但是,该方案以客户库 (Client Library) 的方式集成到服务调用方进程里头,如果企业内有多种不同的语言栈,就要配合开发多种不同的客户端,有一定的研发和维护成本。另外,一旦客户端跟随服务调用方发布到生产环境中,后续如果要对客户库进行升级,势必要求服务调用方修改代码并重新发布,所以该方案的升级推广有不小的阻力。 进程内 LB 的案例是 Netflix 的开源服务框架,对应的组件分别是:Eureka 服务注册表,Karyon 服务端框架支持服务自注册和健康检查,Ribbon 客户端框架支持服务自发现和软路由。另外,阿里开源的服务框架 Dubbo 也是采用类似机制。 第三种是主机独立 LB 进程方案,该方案是针对第二种方案的不足而提出的一种折中方案,原理和第二种方案基本类似,不同之处是,他将 LB 和服务发现功能从进程内移出来,变成主机上的一个独立进程,主机上的一个或者多个服务要访问目标服务时,他们都通过同一主机上的独立 LB 进程做服务发现和负载均衡,见下图 Fig 3。 Fig 3 主机独立 LB 进程方案 该方案也是一种分布式方案,没有单点问题,一个 LB 进程挂了只影响该主机上的服务调用方,服务调用方和 LB 之间是进程内调用,性能好,同时,该方案还简化了服务调用方,不需要为不同语言开发客户库,LB 的升级不需要服务调用方改代码。该方案的不足是部署较复杂,环节多,出错调试排查问题不方便。 该方案的典型案例是 Airbnb 的 SmartStack 服务发现框架,对应组件分别是:Zookeeper 作为服务注册表,Nerve 独立进程负责服务注册和健康检查,Synapse/HAproxy 独立进程负责服务发现和负载均衡。Google 最新推出的基于容器的 PaaS 平台 Kubernetes,其内部服务发现采用类似的机制。 服务前端路由微服务除了内部相互之间调用和通信之外,最终要以某种方式暴露出去,才能让外界系统(例如客户的浏览器、移动设备等等)访问到,这就涉及服务的前端路由,对应的组件是服务网关 (Service Gateway),见图 Fig 4,网关是连接企业内部和外部系统的一道门,有如下关键作用: 服务反向路由,网关要负责将外部请求反向路由到内部具体的微服务,这样虽然企业内部是复杂的分布式微服务结构,但是外部系统从网关上看到的就像是一个统一的完整服务,网关屏蔽了后台服务的复杂性,同时也屏蔽了后台服务的升级和变化。安全认证和防爬虫,所有外部请求必须经过网关,网关可以集中对访问进行安全控制,比如用户认证和授权,同时还可以分析访问模式实现防爬虫功能,网关是连接企业内外系统的安全之门。限流和容错,在流量高峰期,网关可以限制流量,保护后台系统不被大流量冲垮,在内部系统出现故障时,网关可以集中做容错,保持外部良好的用户体验。监控,网关可以集中监控访问量,调用延迟,错误计数和访问模式,为后端的性能优化或者扩容提供数据支持。日志,网关可以收集所有的访问日志,进入后台系统做进一步分析。 Fig 4, 服务网关 除以上基本能力外,网关还可以实现线上引流,线上压测,线上调试 (Surgical debugging),金丝雀测试 (Canary Testing),数据中心双活 (Active-Active HA) 等高级功能。 网关通常工作在 7 层,有一定的计算逻辑,一般以集群方式部署,前置 LB 进行负载均衡。 开源的网关组件有 Netflix 的 Zuul,特点是动态可热部署的过滤器 (filter) 机制,其它如 HAproxy,Nginx 等都可以扩展作为网关使用。 在介绍过服务注册表和网关等组件之后,我们可以通过一个简化的微服务架构图 (Fig 5) 来更加直观地展示整个微服务体系内的服务注册发现和路由机制,该图假定采用进程内 LB 服务发现和负载均衡机制。在下图 Fig 5 的微服务架构中,服务简化为两层,后端通用服务(也称中间层服务 Middle Tier Service)和前端服务(也称边缘服务 Edge Service,前端服务的作用是对后端服务做必要的聚合和裁剪后暴露给外部不同的设备,如 PC,Pad 或者 Phone)。后端服务启动时会将地址信息注册到服务注册表,前端服务通过查询服务注册表就可以发现然后调用后端服务;前端服务启动时也会将地址信息注册到服务注册表,这样网关通过查询服务注册表就可以将请求路由到目标前端服务,这样整个微服务体系的服务自注册自发现和软路由就通过服务注册表和网关串联起来了。如果以面向对象设计模式的视角来看,网关类似 Proxy 代理或者 Façade 门面模式,而服务注册表和服务自注册自发现类似 IoC 依赖注入模式,微服务可以理解为基于网关代理和注册表 IoC 构建的分布式系统。 Fig 5, 简化的微服务架构图 服务容错当企业微服务化以后,服务之间会有错综复杂的依赖关系,例如,一个前端请求一般会依赖于多个后端服务,技术上称为 1 -> N 扇出 (见图 Fig 6)。在实际生产环境中,服务往往不是百分百可靠,服务可能会出错或者产生延迟,如果一个应用不能对其依赖的故障进行容错和隔离,那么该应用本身就处在被拖垮的风险中。在一个高流量的网站中,某个单一后端一旦发生延迟,可能在数秒内导致所有应用资源 (线程,队列等) 被耗尽,造成所谓的雪崩效应 (Cascading Failure,见图 Fig 7),严重时可致整个网站瘫痪。 Fig 6, 服务依赖 Fig 7, 高峰期单个服务延迟致雪崩效应 经过多年的探索和实践,业界在分布式服务容错一块探索出了一套有效的容错模式和最佳实践,主要包括: Fig 8, 弹性电路保护状态图 电路熔断器模式 (Circuit Breaker Patten), 该模式的原理类似于家里的电路熔断器,如果家里的电路发生短路,熔断器能够主动熔断电路,以避免灾难性损失。在分布式系统中应用电路熔断器模式后,当目标服务慢或者大量超时,调用方能够主动熔断,以防止服务被进一步拖垮;如果情况又好转了,电路又能自动恢复,这就是所谓的弹性容错,系统有自恢复能力。下图 Fig 8 是一个典型的具备弹性恢复能力的电路保护器状态图,正常状态下,电路处于关闭状态 (Closed),如果调用持续出错或者超时,电路被打开进入熔断状态 (Open),后续一段时间内的所有调用都会被拒绝 (Fail Fast),一段时间以后,保护器会尝试进入半熔断状态 (Half-Open),允许少量请求进来尝试,如果调用仍然失败,则回到熔断状态,如果调用成功,则回到电路闭合状态。舱壁隔离模式 (Bulkhead Isolation Pattern),顾名思义,该模式像舱壁一样对资源或失败单元进行隔离,如果一个船舱破了进水,只损失一个船舱,其它船舱可以不受影响 。线程隔离 (Thread Isolation) 就是舱壁隔离模式的一个例子,假定一个应用程序 A 调用了 Svc1/Svc2/Svc3 三个服务,且部署 A 的容器一共有 120 个工作线程,采用线程隔离机制,可以给对 Svc1/Svc2/Svc3 的调用各分配 40 个线程,当 Svc2 慢了,给 Svc2 分配的 40 个线程因慢而阻塞并最终耗尽,线程隔离可以保证给 Svc1/Svc3 分配的 80 个线程可以不受影响,如果没有这种隔离机制,当 Svc2 慢的时候,120 个工作线程会很快全部被对 Svc2 的调用吃光,整个应用程序会全部慢下来。限流 (Rate Limiting/Load Shedder),服务总有容量限制,没有限流机制的服务很容易在突发流量 (秒杀,双十一) 时被冲垮。限流通常指对服务限定并发访问量,比如单位时间只允许 100 个并发调用,对超过这个限制的请求要拒绝并回退。回退 (fallback),在熔断或者限流发生的时候,应用程序的后续处理逻辑是什么?回退是系统的弹性恢复能力,常见的处理策略有,直接抛出异常,也称快速失败 (Fail Fast),也可以返回空值或缺省值,还可以返回备份数据,如果主服务熔断了,可以从备份服务获取数据。Netflix 将上述容错模式和最佳实践集成到一个称为 Hystrix 的开源组件中,凡是需要容错的依赖点 (服务,缓存,数据库访问等),开发人员只需要将调用封装在 Hystrix Command 里头,则相关调用就自动置于 Hystrix 的弹性容错保护之下。Hystrix 组件已经在 Netflix 经过多年运维验证,是 Netflix 微服务平台稳定性和弹性的基石,正逐渐被社区接受为标准容错组件。 服务框架微服务化以后,为了让业务开发人员专注于业务逻辑实现,避免冗余和重复劳动,规范研发提升效率,必然要将一些公共关注点推到框架层面。服务框架 (Fig 9) 主要封装公共关注点逻辑,包括: Fig 9, 服务框架 服务注册、发现、负载均衡和健康检查,假定采用进程内 LB 方案,那么服务自注册一般统一做在服务器端框架中,健康检查逻辑由具体业务服务定制,框架层提供调用健康检查逻辑的机制,服务发现和负载均衡则集成在服务客户端框架中。监控日志,框架一方面要记录重要的框架层日志、metrics 和调用链数据,还要将日志、metrics 等接口暴露出来,让业务层能根据需要记录业务日志数据。在运行环境中,所有日志数据一般集中落地到企业后台日志系统,做进一步分析和处理。REST/RPC 和序列化,框架层要支持将业务逻辑以 HTTP/REST 或者 RPC 方式暴露出来,HTTP/REST 是当前主流 API 暴露方式,在性能要求高的场合则可采用 Binary/RPC 方式。针对当前多样化的设备类型 (浏览器、普通 PC、无线设备等),框架层要支持可定制的序列化机制,例如,对浏览器,框架支持输出 Ajax 友好的 JSON 消息格式,而对无线设备上的 Native App,框架支持输出性能高的 Binary 消息格式。配置,除了支持普通配置文件方式的配置,框架层还可集成动态运行时配置,能够在运行时针对不同环境动态调整服务的参数和配置。限流和容错,框架集成限流容错组件,能够在运行时自动限流和容错,保护服务,如果进一步和动态配置相结合,还可以实现动态限流和熔断。管理接口,框架集成管理接口,一方面可以在线查看框架和服务内部状态,同时还可以动态调整内部状态,对调试、监控和管理能提供快速反馈。Spring Boot 微框架的 Actuator 模块就是一个强大的管理接口。统一错误处理,对于框架层和服务的内部异常,如果框架层能够统一处理并记录日志,对服务监控和快速问题定位有很大帮助。安全,安全和访问控制逻辑可以在框架层统一进行封装,可做成插件形式,具体业务服务根据需要加载相关安全插件。文档自动生成,文档的书写和同步一直是一个痛点,框架层如果能支持文档的自动生成和同步,会给使用 API 的开发和测试人员带来极大便利。Swagger 是一种流行 Restful API 的文档方案。当前业界比较成熟的微服务框架有 Netflix 的 Karyon/Ribbon,Spring 的 Spring Boot/Cloud,阿里的 Dubbo 等。 运行期配置管理服务一般有很多依赖配置,例如访问数据库有连接字符串配置,连接池大小和连接超时配置,这些配置在不同环境 (开发 / 测试 / 生产) 一般不同,比如生产环境需要配连接池,而开发测试环境可能不配,另外有些参数配置在运行期可能还要动态调整,例如,运行时根据流量状况动态调整限流和熔断阀值。目前比较常见的做法是搭建一个运行时配置中心支持微服务的动态配置,简化架构如下图 (Fig 10): Fig 10, 服务配置中心 动态配置存放在集中的配置服务器上,用户通过管理界面配置和调整服务配置,具体服务通过定期拉 (Scheduled Pull) 的方式或者服务器推 (Server-side Push) 的方式更新动态配置,拉方式比较可靠,但会有延迟同时有无效网络开销 (假设配置不常更新),服务器推方式能及时更新配置,但是实现较复杂,一般在服务和配置服务器之间要建立长连接。配置中心还要解决配置的版本控制和审计问题,对于大规模服务化环境,配置中心还要考虑分布式和高可用问题。 配置中心比较成熟的开源方案有百度的 Disconf,360 的 QConf,Spring 的 Cloud Config 和阿里的 Diamond 等。 Netflix 的微服务框架Netflix 是一家成功实践微服务架构的互联网公司,几年前,Netflix 就把它的几乎整个微服务框架栈开源贡献给了社区,这些框架和组件包括: Eureka: 服务注册发现框架Zuul: 服务网关Karyon: 服务端框架Ribbon: 客户端框架Hystrix: 服务容错组件Archaius: 服务配置组件Servo: Metrics 组件Blitz4j: 日志组件下图 Fig 11 展示了基于这些组件构建的一个微服务框架体系,来自 recipes-rss。 Fig 11, 基于 Netflix 开源组件的微服务框架 Netflix 的开源框架组件已经在 Netflix 的大规模分布式微服务环境中经过多年的生产实战验证,正逐步被社区接受为构造微服务框架的标准组件。Pivotal 去年推出的 Spring Cloud 开源产品,主要是基于对 Netflix 开源组件的进一步封装,方便 Spring 开发人员构建微服务基础框架。对于一些打算构建微服务框架体系的公司来说,充分利用或参考借鉴 Netflix 的开源微服务组件 (或 Spring Cloud),在此基础上进行必要的企业定制,无疑是通向微服务架构的捷径。 原文地址:https://www.infoq.cn/article/basis-frameworkto-implement-micro-service#anch130564%20%EF%BC%8C

auto_answer 2019-12-02 01:55:22 0 浏览量 回答数 0

问题

[精品问答]Java一百问第一期

问问小秘 2019-12-01 21:51:20 791 浏览量 回答数 1

回答

"500根本不大,没有达到tomcat的极限的,所以看你业务的。。业务代码有问题,50个不也照样跑满么######的确,代码问题。######一台tomcat 通常分配500个请求的,你可以用nginx 做代理转发,后端起多个tomcat######回复 <a href=""http://my.oschina.net/295117485"" class=""referer"" target=""_blank"">@-Jacen- : 我测试出来windows 下没很大差别######昨天问了一个朋友,说windows下apache比nginx性能高。是这样吗?######超时时间太长了,你这样直接就把服务器拖死了######你说的超时时间是指connectionTimeout 还是keepAliveTimeout###### 如何定义高并发? 上线前酝酿一下最高的并发请求数,针对请求数做2/8法则, 压力测试单台容器能支撑多久... 最后建议搞集群把...分担压力. ######nginx在前面,毕竟tomcat并不是为大并发设计的!还有,你的每个请求运行逻辑不要太复杂,不要占用过长时间######500台手机在线,真正的并发约为20-40%之间,一台tomcat完全可以抗的住,修改tomcat的连接数同时看下OS的文件打开数限制,另外开始压缩,最好前面用nginx反向代理######回复 @Eric_林 : 嗯,都不熟悉,到处乱搞。######回复 @-Jacen- : 都差不多,看你哪个更熟悉######windows作为服务器,用apache还是nginx更好?######你这一个processTime  这么久? 最长的半个小时,一台tomcat   请求多了 你不挂 谁挂 ######回复 @-Jacen- : 悲观锁:一旦你数据库处理稍微久 并发量上来 会导致链接不够用,然后任务被拒绝。 乐观锁:会导致很多无效的mysql操作,同样会消耗很多资源。 所以要具体业务场景及根据系统可预想的并发量进行具体分析,一种比较好的方式是用redis协助来做乐观锁,还有一种就是redis的原子性操作是一种更好的方式,再或者用redis的lua方式。反正就是具体业务要具体分析,哈哈哈哈哈######回复 @Ambitor : 为了防止多线程重复都数据库,加了个synchronized锁,结果一段时间就挂了,后来去掉,就好了。现在有个思路通过数据库悲观锁或者乐观锁解决。######回复 @-Jacen- : 还有如果你都是长连接的话,那你可能就要用集群了######回复 @-Jacen- : 我觉得线程5000个是多了,然后空闲存活时间只有60秒。但是JDK的线程池的创建策略是任务队列排不下了再新建线程的,所以如果你的应用规模没达到每秒上百的并发(注意,我说的是并发,不是同时在线) 应该不是问题,所以这个地方问题 应该是你的业务逻辑代码有问题?仔细研究下你们代码是不是有某些问题?不然一个请求怎么这么久。######就是不清楚为啥这个time会这么久。求指点######你搞这么大的线程,线程切换估计都浪费很多cpu了######负载均衡呢######建议前面加nginx( 配置比apache简单),后面改成多个tomcat。"

montos 2020-06-03 22:31:00 0 浏览量 回答数 0

问题

生产环境中的 Redis 是怎么部署的?【Java问答】40期

剑曼红尘 2020-06-18 08:28:34 33 浏览量 回答数 1

问题

荆门开诊断证明-scc

游客5k2abgdj3m2ti 2019-12-01 22:09:00 1 浏览量 回答数 0

问题

利用PHP长连接如何提高使用OCS的性能

云栖大讲堂 2019-12-01 21:31:07 1178 浏览量 回答数 0

问题

【精品问答】Java技术1000问(1)

问问小秘 2019-12-01 21:57:43 37578 浏览量 回答数 11

问题

【阿里云产品公测】以开发者角度看ACE服务『ACE应用构建指南』

mr_wid 2019-12-01 21:10:06 20092 浏览量 回答数 6

回答

在开始谈我对架构本质的理解之前,先谈谈对今天技术沙龙主题的个人见解,千万级规模的网站感觉数量级是非常大的,对这个数量级我们战略上 要重 视 它 , 战术上又 要 藐 视 它。先举个例子感受一下千万级到底是什么数量级?现在很流行的优步(Uber),从媒体公布的信息看,它每天接单量平均在百万左右, 假如每天有10个小时的服务时间,平均QPS只有30左右。对于一个后台服务器,单机的平均QPS可以到达800-1000,单独看写的业务量很简单 。为什么我们又不能说轻视它?第一,我们看它的数据存储,每天一百万的话,一年数据量的规模是多少?其次,刚才说的订单量,每一个订单要推送给附近的司机、司机要并发抢单,后面业务场景的访问量往往是前者的上百倍,轻松就超过上亿级别了。 今天我想从架构的本质谈起之后,希望大家理解在做一些建构设计的时候,它的出发点以及它解决的问题是什么。 架构,刚开始的解释是我从知乎上看到的。什么是架构?有人讲, 说架构并不是一 个很 悬 乎的 东西 , 实际 上就是一个架子 , 放一些 业务 和算法,跟我们的生活中的晾衣架很像。更抽象一点,说架构其 实 是 对 我 们 重复性业务 的抽象和我 们 未来 业务 拓展的前瞻,强调过去的经验和你对整个行业的预见。 我们要想做一个架构的话需要哪些能力?我觉得最重要的是架构师一个最重要的能力就是你要有 战 略分解能力。这个怎么来看呢: 第一,你必须要有抽象的能力,抽象的能力最基本就是去重,去重在整个架构中体现在方方面面,从定义一个函数,到定义一个类,到提供的一个服务,以及模板,背后都是要去重提高可复用率。 第二, 分类能力。做软件需要做对象的解耦,要定义对象的属性和方法,做分布式系统的时候要做服务的拆分和模块化,要定义服务的接口和规范。 第三, 算法(性能),它的价值体现在提升系统的性能,所有性能的提升,最终都会落到CPU,内存,IO和网络这4大块上。 这一页PPT举了一些例子来更深入的理解常见技术背后的架构理念。 第一个例子,在分布式系统我们会做 MySQL分 库 分表,我们要从不同的库和表中读取数据,这样的抽象最直观就是使用模板,因为绝大多数SQL语义是相同的,除了路由到哪个库哪个表,如果不使用Proxy中间件,模板就是性价比最高的方法。 第二看一下加速网络的CDN,它是做速度方面的性能提升,刚才我们也提到从CPU、内存、IO、网络四个方面来考虑,CDN本质上一个是做网络智能调度优化,另一个是多级缓存优化。 第三个看一下服务化,刚才已经提到了,各个大网站转型过程中一定会做服务化,其实它就是做抽象和做服务的拆分。第四个看一下消息队列,本质上还是做分类,只不过不是两个边际清晰的类,而是把两个边际不清晰的子系统通过队列解构并且异步化。新浪微博整体架构是什么样的 接下我们看一下微博整体架构,到一定量级的系统整个架构都会变成三层,客户端包括WEB、安卓和IOS,这里就不说了。接着还都会有一个接口层, 有三个主要作用: 第一个作用,要做 安全隔离,因为前端节点都是直接和用户交互,需要防范各种恶意攻击; 第二个还充当着一个 流量控制的作用,大家知道,在2014年春节的时候,微信红包,每分钟8亿多次的请求,其实真正到它后台的请求量,只有十万左右的数量级(这里的数据可能不准),剩余的流量在接口层就被挡住了; 第三,我们看对 PC 端和移 动 端的需求不一样的,所以我们可以进行拆分。接口层之后是后台,可以看到微博后台有三大块: 一个是 平台服 务, 第二, 搜索, 第三, 大数据。到了后台的各种服务其实都是处理的数据。 像平台的业务部门,做的就是 数据存储和读 取,对搜索来说做的是 数据的 检 索,对大数据来说是做的数据的 挖掘。微博其实和淘宝是很类似 微博其实和淘宝是很类似的。一般来说,第一代架构,基本上能支撑到用户到 百万 级别,到第二代架构基本能支撑到 千万 级别都没什么问题,当业务规模到 亿级别时,需要第三代的架构。 从 LAMP 的架构到面向服 务 的架构,有几个地方是非常难的,首先不可能在第一代基础上通过简单的修修补补满足用户量快速增长的,同时线上业务又不能停, 这是我们常说的 在 飞 机上 换 引擎的 问题。前两天我有一个朋友问我,说他在内部推行服务化的时候,把一个模块服务化做完了,其他部门就是不接。我建议在做服务化的时候,首先更多是偏向业务的梳理,同时要找准一个很好的切入点,既有架构和服务化上的提升,业务方也要有收益,比如提升性能或者降低维护成本同时升级过程要平滑,建议开始从原子化服务切入,比如基础的用户服务, 基础的短消息服务,基础的推送服务。 第二,就是可 以做无状 态 服 务,后面会详细讲,还有数据量大了后需要做数据Sharding,后面会将。 第三代 架构 要解决的 问题,就是用户量和业务趋于稳步增加(相对爆发期的指数级增长),更多考虑技术框架的稳定性, 提升系统整体的性能,降低成本,还有对整个系统监控的完善和升级。 大型网站的系统架构是如何演变的 我们通过通过数据看一下它的挑战,PV是在10亿级别,QPS在百万,数据量在千亿级别。我们可用性,就是SLA要求4个9,接口响应最多不能超过150毫秒,线上所有的故障必须得在5分钟内解决完。如果说5分钟没处理呢?那会影响你年终的绩效考核。2015年微博DAU已经过亿。我们系统有上百个微服务,每周会有两次的常规上线和不限次数的紧急上线。我们的挑战都一样,就是数据量,bigger and bigger,用户体验是faster and faster,业务是more and more。互联网业务更多是产品体验驱动, 技 术 在 产 品 体验上最有效的贡献 , 就是你的性能 越来越好 。 每次降低加载一个页面的时间,都可以间接的降低这个页面上用户的流失率。微博的技术挑战和正交分解法解析架构 下面看一下 第三代的 架构 图 以及 我 们 怎么用正交分解法 阐 述。 我们可以看到我们从两个维度,横轴和纵轴可以看到。 一个 维 度 是 水平的 分层 拆分,第二从垂直的维度会做拆分。水平的维度从接口层、到服务层到数据存储层。垂直怎么拆分,会用业务架构、技术架构、监控平台、服务治理等等来处理。我相信到第二代的时候很多架构已经有了业务架构和技术架构的拆分。我们看一下, 接口层有feed、用户关系、通讯接口;服务层,SOA里有基层服务、原子服务和组合服务,在微博我们只有原子服务和组合服务。原子服务不依赖于任何其他服务,组合服务由几个原子服务和自己的业务逻辑构建而成 ,资源层负责海量数据的存储(后面例子会详细讲)。技 术框架解决 独立于 业务 的海量高并发场景下的技术难题,由众多的技术组件共同构建而成 。在接口层,微博使用JERSY框架,帮助你做参数的解析,参数的验证,序列化和反序列化;资源层,主要是缓存、DB相关的各类组件,比如Cache组件和对象库组件。监 控平台和服 务 治理 , 完成系统服务的像素级监控,对分布式系统做提前诊断、预警以及治理。包含了SLA规则的制定、服务监控、服务调用链监控、流量监控、错误异常监控、线上灰度发布上线系统、线上扩容缩容调度系统等。 下面我们讲一下常见的设计原则。 第一个,首先是系统架构三个利器: 一个, 我 们 RPC 服 务组 件 (这里不讲了), 第二个,我们 消息中 间 件 。消息中间件起的作用:可以把两个模块之间的交互异步化,其次可以把不均匀请求流量输出为匀速的输出流量,所以说消息中间件 异步化 解耦 和流量削峰的利器。 第三个是配置管理,它是 代码级灰度发布以及 保障系统降级的利器。 第二个 , 无状态 , 接口 层 最重要的就是无状 态。我们在电商网站购物,在这个过程中很多情况下是有状态的,比如我浏览了哪些商品,为什么大家又常说接口层是无状态的,其实我们把状态从接口层剥离到了数据层。像用户在电商网站购物,选了几件商品,到了哪一步,接口无状态后,状态要么放在缓存中,要么放在数据库中, 其 实 它并不是没有状 态 , 只是在 这 个 过 程中我 们 要把一些有状 态 的 东 西抽离出来 到了数据层。 第三个, 数据 层 比服 务层 更需要 设计,这是一条非常重要的经验。对于服务层来说,可以拿PHP写,明天你可以拿JAVA来写,但是如果你的数据结构开始设计不合理,将来数据结构的改变会花费你数倍的代价,老的数据格式向新的数据格式迁移会让你痛不欲生,既有工作量上的,又有数据迁移跨越的时间周期,有一些甚至需要半年以上。 第四,物理结构与逻辑结构的映射,上一张图看到两个维度切成十二个区间,每个区间代表一个技术领域,这个可以看做我们的逻辑结构。另外,不论后台还是应用层的开发团队,一般都会分几个垂直的业务组加上一个基础技术架构组,这就是从物理组织架构到逻辑的技术架构的完美的映射,精细化团队分工,有利于提高沟通协作的效率 。 第五, www .sanhao.com 的访问过程,我们这个架构图里没有涉及到的,举个例子,比如当你在浏览器输入www.sanhao网址的时候,这个请求在接口层之前发生了什么?首先会查看你本机DNS以及DNS服务,查找域名对应的IP地址,然后发送HTTP请求过去。这个请求首先会到前端的VIP地址(公网服务IP地址),VIP之后还要经过负载均衡器(Nginx服务器),之后才到你的应用接口层。在接口层之前发生了这么多事,可能有用户报一个问题的时候,你通过在接口层查日志根本发现不了问题,原因就是问题可能发生在到达接口层之前了。 第六,我们说分布式系统,它最终的瓶颈会落在哪里呢?前端时间有一个网友跟我讨论的时候,说他们的系统遇到了一个瓶颈, 查遍了CPU,内存,网络,存储,都没有问题。我说你再查一遍,因为最终你不论用上千台服务器还是上万台服务器,最终系统出瓶颈的一定会落在某一台机(可能是叶子节点也可能是核心的节点),一定落在CPU、内存、存储和网络上,最后查出来问题出在一台服务器的网卡带宽上。微博多级双机房缓存架构 接下来我们看一下微博的Feed多级缓存。我们做业务的时候,经常很少做业务分析,技术大会上的分享又都偏向技术架构。其实大家更多的日常工作是需要花费更多时间在业务优化上。这张图是统计微博的信息流前几页的访问比例,像前三页占了97%,在做缓存设计的时候,我们最多只存最近的M条数据。 这里强调的就是做系统设计 要基于用 户 的 场 景 , 越细致越好 。举了一个例子,大家都会用电商,电商在双十一会做全国范围内的活动,他们做设计的时候也会考虑场景的,一个就是购物车,我曾经跟相关开发讨论过,购物车是在双十一之前用户的访问量非常大,就是不停地往里加商品。在真正到双十一那天他不会往购物车加东西了,但是他会频繁的浏览购物车。针对这个场景,活动之前重点设计优化购物车的写场景, 活动开始后优化购物车的读场景。 你看到的微博是由哪些部分聚合而成的呢?最右边的是Feed,就是微博所有关注的人,他们的微博所组成的。微博我们会按照时间顺序把所有关注人的顺序做一个排序。随着业务的发展,除了跟时间序相关的微博还有非时间序的微博,就是会有广告的要求,增加一些广告,还有粉丝头条,就是拿钱买的,热门微博,都会插在其中。分发控制,就是说和一些推荐相关的,我推荐一些相关的好友的微博,我推荐一些你可能没有读过的微博,我推荐一些其他类型的微博。 当然对非时序的微博和分发控制微博,实际会起多个并行的程序来读取,最后同步做统一的聚合。这里稍微分享一下, 从SNS社交领域来看,国内现在做的比较好的三个信息流: 微博 是 基于弱关系的媒体信息流 ; 朋友圈是基于 强 关系的信息流 ; 另外一个做的比 较 好的就是今日 头 条 , 它并不是基于关系来构建信息流 , 而是基于 兴趣和相关性的个性化推荐 信息流 。 信息流的聚合,体现在很多很多的产品之中,除了SNS,电商里也有信息流的聚合的影子。比如搜索一个商品后出来的列表页,它的信息流基本由几部分组成:第一,打广告的;第二个,做一些推荐,热门的商品,其次,才是关键字相关的搜索结果。 信息流 开始的时候 很 简单 , 但是到后期会 发现 , 你的 这 个流 如何做控制分发 , 非常复杂, 微博在最近一两年一直在做 这样 的工作。刚才我们是从业务上分析,那么技术上怎么解决高并发,高性能的问题?微博访问量很大的时候,底层存储是用MySQL数据库,当然也会有其他的。对于查询请求量大的时候,大家知道一定有缓存,可以复用可重用的计算结果。可以看到,发一条微博,我有很多粉丝,他们都会来看我发的内容,所以 微博是最适合使用 缓 存 的系统,微博的读写比例基本在几十比一。微博使用了 双 层缓 存,上面是L1,每个L1上都是一组(包含4-6台机器),左边的框相当于一个机房,右边又是一个机房。在这个系统中L1缓存所起的作用是什么? 首先,L1 缓 存增加整个系 统 的 QPS, 其次 以低成本灵活扩容的方式 增加 系统 的 带宽 。想象一个极端场景,只有一篇博文,但是它的访问量无限增长,其实我们不需要影响L2缓存,因为它的内容存储的量小,但它就是访问量大。这种场景下,你就需要使用L1来扩容提升QPS和带宽瓶颈。另外一个场景,就是L2级缓存发生作用,比如我有一千万个用户,去访问的是一百万个用户的微博 ,这个时候,他不只是说你的吞吐量和访问带宽,就是你要缓存的博文的内容也很多了,这个时候你要考虑缓存的容量, 第二 级缓 存更多的是从容量上来 规划,保证请求以较小的比例 穿透到 后端的 数据 库 中 ,根据你的用户模型你可以估出来,到底有百分之多少的请求不能穿透到DB, 评估这个容量之后,才能更好的评估DB需要多少库,需要承担多大的访问的压力。另外,我们看双机房的话,左边一个,右边一个。 两个机房是互 为 主 备 , 或者互 为热备 。如果两个用户在不同地域,他们访问两个不同机房的时候,假设用户从IDC1过来,因为就近原理,他会访问L1,没有的话才会跑到Master,当在IDC1没找到的时候才会跑到IDC2来找。同时有用户从IDC2访问,也会有请求从L1和Master返回或者到IDC1去查找。 IDC1 和 IDC2 ,两个机房都有全量的用户数据,同时在线提供服务,但是缓存查询又遵循最近访问原理。还有哪些多级缓存的例子呢?CDN是典型的多级缓存。CDN在国内各个地区做了很多节点,比如在杭州市部署一个节点时,在机房里肯定不止一台机器,那么对于一个地区来说,只有几台服务器到源站回源,其他节点都到这几台服务器回源即可,这么看CDN至少也有两级。Local Cache+ 分布式 缓 存,这也是常见的一种策略。有一种场景,分布式缓存并不适用, 比如 单 点 资 源 的爆发性峰值流量,这个时候使用Local Cache + 分布式缓存,Local Cache 在 应用 服 务 器 上用很小的 内存资源 挡住少量的 极端峰值流量,长尾的流量仍然访问分布式缓存,这样的Hybrid缓存架构通过复用众多的应用服务器节点,降低了系统的整体成本。 我们来看一下 Feed 的存 储 架构,微博的博文主要存在MySQL中。首先来看内容表,这个比较简单,每条内容一个索引,每天建一张表,其次看索引表,一共建了两级索引。首先想象一下用户场景,大部分用户刷微博的时候,看的是他关注所有人的微博,然后按时间来排序。仔细分析发现在这个场景下, 跟一个用户的自己的相关性很小了。所以在一级索引的时候会先根据关注的用户,取他们的前条微博ID,然后聚合排序。我们在做哈希(分库分表)的时候,同时考虑了按照UID哈希和按照时间维度。很业务和时间相关性很高的,今天的热点新闻,明天就没热度了,数据的冷热非常明显,这种场景就需要按照时间维度做分表,首先冷热数据做了分离(可以对冷热数据采用不同的存储方案来降低成本),其次, 很容止控制我数据库表的爆炸。像微博如果只按照用户维度区分,那么这个用户所有数据都在一张表里,这张表就是无限增长的,时间长了查询会越来越慢。二级索引,是我们里面一个比较特殊的场景,就是我要快速找到这个人所要发布的某一时段的微博时,通过二级索引快速定位。 分布式服务追踪系统 分布式追踪服务系统,当系统到千万级以后的时候,越来越庞杂,所解决的问题更偏向稳定性,性能和监控。刚才说用户只要有一个请求过来,你可以依赖你的服务RPC1、RPC2,你会发现RPC2又依赖RPC3、RPC4。分布式服务的时候一个痛点,就是说一个请求从用户过来之后,在后台不同的机器之间不停的调用并返回。 当你发现一个问题的时候,这些日志落在不同的机器上,你也不知道问题到底出在哪儿,各个服务之间互相隔离,互相之间没有建立关联。所以导致排查问题基本没有任何手段,就是出了问题没法儿解决。 我们要解决的问题,我们刚才说日志互相隔离,我们就要把它建立联系。建立联系我们就有一个请求ID,然后结合RPC框架, 服务治理功能。假设请求从客户端过来,其中包含一个ID 101,到服务A时仍然带有ID 101,然后调用RPC1的时候也会标识这是101 ,所以需要 一个唯一的 请求 ID 标识 递归迭代的传递到每一个 相关 节点。第二个,你做的时候,你不能说每个地方都加,对业务系统来说需要一个框架来完成这个工作, 这 个框架要 对业务 系 统 是最低侵入原 则 , 用 JAVA 的 话 就可以用 AOP,要做到零侵入的原则,就是对所有相关的中间件打点,从接口层组件(HTTP Client、HTTP Server)至到服务层组件(RPC Client、RPC Server),还有数据访问中间件的,这样业务系统只需要少量的配置信息就可以实现全链路监控 。为什么要用日志?服务化以后,每个服务可以用不同的开发语言, 考虑多种开发语言的兼容性 , 内部定 义标 准化的日志 是唯一且有效的办法。最后,如何构建基于GPS导航的路况监控?我们刚才讲分布式服务追踪。分布式服务追踪能解决的问题, 如果 单一用 户发现问题 后 , 可以通 过请 求 ID 快速找到 发 生 问题 的 节 点在什么,但是并没有解决如何发现问题。我们看现实中比较容易理解的道路监控,每辆车有GPS定位,我想看北京哪儿拥堵的时候,怎么做? 第一个 , 你肯定要知道每个 车 在什么位置,它走到哪儿了。其实可以说每个车上只要有一个标识,加上每一次流动的信息,就可以看到每个车流的位置和方向。 其次如何做 监 控和 报 警,我们怎么能了解道路的流量状况和负载,并及时报警。我们要定义这条街道多宽多高,单位时间可以通行多少辆车,这就是道路的容量。有了道路容量,再有道路的实时流量,我们就可以基于实习路况做预警? 对应于 分布式系 统 的话如何构建? 第一 , 你要 定义 每个服 务节 点它的 SLA A 是多少 ?SLA可以从系统的CPU占用率、内存占用率、磁盘占用率、QPS请求数等来定义,相当于定义系统的容量。 第二个 , 统计 线 上 动态 的流量,你要知道服务的平均QPS、最低QPS和最大QPS,有了流量和容量,就可以对系统做全面的监控和报警。 刚才讲的是理论,实际情况肯定比这个复杂。微博在春节的时候做许多活动,必须保障系统稳定,理论上你只要定义容量和流量就可以。但实际远远不行,为什么?有技术的因素,有人为的因素,因为不同的开发定义的流量和容量指标有主观性,很难全局量化标准,所以真正流量来了以后,你预先评估的系统瓶颈往往不正确。实际中我们在春节前主要采取了三个措施:第一,最简单的就是有降 级 的 预 案,流量超过系统容量后,先把哪些功能砍掉,需要有明确的优先级 。第二个, 线上全链路压测,就是把现在的流量放大到我们平常流量的五倍甚至十倍(比如下线一半的服务器,缩容而不是扩容),看看系统瓶颈最先发生在哪里。我们之前有一些例子,推测系统数据库会先出现瓶颈,但是实测发现是前端的程序先遇到瓶颈。第三,搭建在线 Docker 集群 , 所有业务共享备用的 Docker集群资源,这样可以极大的避免每个业务都预留资源,但是实际上流量没有增长造成的浪费。 总结 接下来说的是如何不停的学习和提升,这里以Java语言为例,首先, 一定要 理解 JAVA;第二步,JAVA完了以后,一定要 理 解 JVM;其次,还要 理解 操作系统;再次还是要了解一下 Design Pattern,这将告诉你怎么把过去的经验抽象沉淀供将来借鉴;还要学习 TCP/IP、 分布式系 统、数据结构和算法。

hiekay 2019-12-02 01:39:25 0 浏览量 回答数 0

回答

前言概述 本文介绍了使用函数计算部署深度学习 AI 推理的最佳实践, 其中包括使用 FUN 工具一键部署安装第三方依赖、一键部署、本地调试以及压测评估, 全方位展现函数计算的开发敏捷特性、自动弹性伸缩能力、免运维和完善的监控设施。 1.1 DEMO 概述 image 通过上传一个猫或者狗的照片, 识别出这个照片里面的动物是猫还是狗 DEMO 示例效果入口: http://sz.mofangdegisn.cn DEMO 示例工程地址: https://github.com/awesome-fc/cat-dog-classify 开通服务 免费开通函数计算, 按量付费,函数计算有很大的免费额度。 免费开通文件存储服务NAS, 按量付费 1.2 解决方案 image 如上图所示, 当多个用户通过对外提供的 url 访问推理服务时候,每秒的请求几百上千都没有关系, 函数计算平台会自动伸缩, 提供足够的执行实例来响应用户的请求, 同时函数计算提供了完善的监控设施来监控您的函数运行情况。 1.3. Serverless 方案与传统自建服务方案对比 1.3.1 卓越的工程效率 自建服务 函数计算 Serverless 基础设施 需要用户采购和管理 无 开发效率 除了必要的业务逻辑开发,需要自己建立相同线上运行环境, 包括相关软件的安装、服务配置、安全更新等一系列问题 只需要专注业务逻辑的开发, 配合 FUN 工具一键资源编排和部署 学习上手成本 可能使用 K8S 或弹性伸缩( ESS ),需要了解更多的产品、名词和参数的意义 会编写对应的语言的函数代码即可 1.3.2 弹性伸缩免运维 自建服务 函数计算 Serverless 弹性高可用 需要自建负载均衡 (SLB),弹性伸缩,扩容缩容速度较 FC 慢 FC系统固有毫秒级别弹性伸缩,快速实现底层扩容以应对峰值压力,免运维 监控报警查询 ECS 级别的 metrics 提供更细粒度的函数执行情况,每次访问函数执行的 latency 和日志等, 更加完善的报警监控机制 1.3.3 更低的成本 函数计算 (FC) 固有自动伸缩和负载均衡功能,用户不需要购买负载均衡 (SLB) 和弹性伸缩。 具有明显波峰波谷的用户访问场景(比如只有部分时间段有请求,其他时间甚至没有请求),选择按需付费,只需为实际使用的计算资源付费。 对于明显波峰波谷或者稀疏调用具有低成本优势, 同时还保持了弹性能力,以后业务规模做大以后并没有技术切换成本,同时财务成本增长配合预付费也能保持平滑。 部分请求持续平稳的场景下,可以配合预付费解决按需付费较高单价问题。函数计算成本优化最佳实践文档。 假设有一个在线计算服务,由于是CPU 密集型计算, 因此在这里我们将平均 CPU 利用率作为核心参考指标对成本,以一个月为周期,10台 C5 ECS 的总计算力为例,总的计算量约为 30% 场景下, 各解决方案 CPU 资源利用率使用情况示意图大致如下: image 由上图预估出如下计费模型: 函数计算预付费 3CU 一个月: 246.27 元, 计算能力等价于 ECS 计算型 C5 ECS 计算型 C5 (2vCPU,4GB)+云盘: 包月219 元,按量: 446.4 元 包月10 Mbps 的 SLB: 526.52 元(这里做了一定的流量假设), 弹性伸缩免费 饱和使用下,函数计算按量付费的一台机器成本约为按量付费 C5 ECS 的2 倍 平均CPU使用率 计算费用 SLB 总计 函数计算组合付费 >=80% 738+X(246.273+X) 无 <= 738+X 按峰值预留ECS <=30% 2190(10219) 526.52 >=2716.52 弹性伸缩延迟敏感 <=50% 1314(102193/5) 526.52 >= 1840.52 弹性伸缩成本敏感 <=70% 938.57 (102193/7) 526.52 >= 1465.09 注: 这里假设函数逻辑没有公网下行流量费用, 即使有也是一致的, 这里成本比较暂不参与 延时敏感,当 CPU 利用率大于等于 50% 就需要开始进行扩容,不然更来不及应对峰值 成本敏感,当 CPU 利用率大约 80% 即开始进行扩容, 能容受一定几率的超时或者5XX 上表中, 其中函数计算组合付费中的 X 为按需付费的成本价,假设按需付费的计算量占整个计算量的 10%,假设 CPU 利用率为100%, 对应上表,那么需要 3 台 ECS 的计算能力即可。因此 FC 按量付费的成本 X = 3 ️ 446.4 ️ 10% ️ 2 = 267.84 ( FC 按量付费是按量 ECS 的2倍),这个时候函数计算组合付费总计 1005.8 元。 在这个模型预估里面, 只要 FC 按量付费占整个计算量小于 20%, 即使不考虑 SLB, 单纯考虑计算成本, 都是有一定优势的。 1.3.4. 小结 基于函数计算进行 AI 推理等 CPU 密集型的主要优势: 上手简单, 只专注业务逻辑开发, 极大提高工程开发效率。 自建方案有太多学习和配置成本,如针对不同场景,ESS 需要做各种不同的参数配置 系统环境的维护升级等 免运维,函数执行级别粒度的监控和告警。 毫秒级弹性扩容,保证弹性高可用,同时能覆盖延迟敏感和成本敏感类型。 在 CPU 密集型的计算场景下, 通过设置合理的组合计费模式, 在如下场景中具有成本优势: 请求访问具有明显波峰波谷, 其他时间甚至没有请求 有一定稳定的负载请求, 但是有部分时间段请求量突变剧烈 打包代码ZIP包和部署函数 FUN 操作简明视频教程 开通服务 免费开通函数计算, 按量付费,函数计算有很大的免费额度。 免费开通文件存储服务NAS, 按量付费 2.1 安装第三方包到本地并上传到NAS 2.1.1 安装最新的Fun 安装版本为8.x 最新版或者10.x 、12.x nodejs 安装 funcraf 2.1.2 Clone 工程 & Fun 一键安装第三方库到本地 git clone https://github.com/awesome-fc/cat-dog-classify.git 复制 .env_example 文件为 .env, 并且修改 .env 中的信息为自己的信息 执行 fun install -v, fun 会根据 Funfile 中定义的逻辑安装相关的依赖包 image root@66fb3ad27a4c: ls .fun/nas/auto-default/classify model python root@66fb3ad27a4c: du -sm .fun 697 .fun 根据 Funfile 的定义: 将第三方库下载到 .fun/nas/auto-default/classify/python 目录下 本地 model 目录移到 .fun/nas/auto-default/model 目录下 安装完成后,从这里我们看出, 函数计算引用的代码包解压之后已经达到了 670 M, 远超过 50M 代码包限制, 解决方案是 NAS 详情可以参考: 挂载NAS访问,幸运的是 FUN 工具一键解决了 nas 的配置和文件上传问题。 2.1.3. 将下载的依赖的第三方代码包上传到 NAS fun nas init fun nas info fun nas sync fun nas ls nas://classify:/mnt/auto/ 依次执行这些命令,就将本地中的 .fun/nas/auto-default 中的第三方代码包和模型文件传到 NAS 中, 依次看下这几个命令的做了什么事情: fun nas init: 初始化 NAS, 基于您的 .env 中的信息获取(已有满足条件的nas)或创建一个同region可用的nas fun nas info: 可以查看本地 NAS 的目录位置, 对于此工程是 $(pwd)/.fun/nas/auto-default/classify fun nas sync: 将本地 NAS 中的内容(.fun/nas/auto-default/classify)上传到 NAS 中的 classify 目录 fun nas ls nas:///mnt/auto/: 查看我们是否已经正确将文件上传到了 NAS 登录 NAS 控制台 https://nas.console.aliyun.com 和 VPC 控制台 https://vpc.console.aliyun.com可以观察到在指定的 region 上有 NAS 和相应的 vpc 创建成功 2.2 本地调试函数 在 template.yml 中, 指定了这个函数是 http 类型的函数, 所以根据 fun 的提示: Tips for next step Invoke Event Function: fun local invokeInvoke Http Function: fun local startBuild Http Function: fun buildDeploy Resources: fun deploy 执行 fun local start, 本地就会启动一个 http server 来模拟函数的执行, 然后我们 client 端可以使用 postman, curl 或者浏览器, 比如对于本例: image image 2.3 部署函数到FC平台 本地调试OK 后,我们接下来将函数部署到云平台: 修改 template.yml LogConfig 中的 Project, 任意取一个不会重复的名字即可,有两处地方需要更改,然后执行 fun deploy 注意: template.yml 注释的部分为自定义域名的配置, 如果想在 fun deploy 中完成这个部署工作: 先去域名解析, 比如在示例中, 将域名 sz.mofangdegisn.cn 解析到 123456.cn-hangzhou.fc.aliyuncs.com, 对应的域名、accountId 和 region 修改成自己的 去掉 template.yml 中的注释, 修改成自己的域名 执行 fun deploy 这个时候如果没有自定义域名, 直接通过浏览器访问http trigger 的url, 比如 https://123456.cn-shenzhen.fc.aliyuncs.com/2016-08-15/proxy/classify/cat-dog/ 会被强制下载. 原因:https://help.aliyun.com/knowledge_detail/56103.html#HTTP-Trigger-compulsory-header image 登录控制台https://fc.console.aliyun.com,可以看到service 和函数已经创建成功,并且 service 也已经正确配置。 image 在这里,我们发现第一次打开页面访问函数的时候,执行环境实例冷启动时间非常长, 如果是一个在线AI推理服务,对响应时间非常敏感,冷启动引起的毛刺对于这种类型的服务是不可接受的,接下来,本文讲解如何利用函数计算的预留模式来消除冷启动带来的负面影响。 使用预留模式消除冷启动毛刺 函数计算具有动态伸缩的特性, 根据并发请求量,自动弹性扩容出执行环境来执行环境,在这个典型的深度学习示例中,import keras 消耗的时间很长 , 在我们设置的 1 G 规格的函数中, 并发访问的时候耗时10s左右, 有时甚至20s+ start = time.time() from keras.models import model_from_json print("import keras time = ", time.time()-start) 3.1 函数计算设置预留 预留操作简明视频教程 在 FC 控制台,发布版本,并且基于该版本创建别名 prod,并且基于别名 prod 设置预留, 操作过程请参考:https://help.aliyun.com/document_detail/138103.html 将该函数的 http trigger 和自定义域名的设置执行 prod 版本 image image 一次压测结果 imageimage 从上面图中我们可以看出,当函数执行的请求到来时,优先被调度到预留的实例中被执行, 这个时候是没有冷启动的,所以请求是没有毛刺的, 后面随着测试的压力不断增大(峰值TPS 达到 1184), 预留的实例不能满足调用函数的请求, 这个时候函数计算就自动进行按需扩容实例供函数执行,此时的调用就有冷启动的过程, 从上面我们可以看出,函数的最大 latency 时间甚至达到了 32s,如果这个web AP是延时敏感的,这个 latency 是不可接受的。 总结 函数计算具有快速自动伸缩扩容能力 预留模式很好地解决了冷启动中的毛刺问题 开发简单易上手,只需要关注具体的代码逻辑, Fun 工具助您一键式部署运用 函数计算具有很好监控设施, 您可以可视化观察您函数运行情况, 执行时间、内存等信息

1934890530796658 2020-03-27 18:21:48 0 浏览量 回答数 0

回答

Nginx是一个轻量级的,高性能的Web服务器以及反向代理和邮箱 (IMAP/POP3)代理服务器。它运行在UNIX,GNU /linux,BSD 各种版本,Mac OS X,Solaris和Windows。根据调查统计,6%的网站使用Nginx Web服务器。Nginx是少数能处理C10K问题的服务器之一。跟传统的服务器不同,Nginx不依赖线程来处理请求。相反,它使用了更多的可扩展的事 件驱动(异步)架构。Nginx为一些高流量的网站提供动力,比如WordPress,人人网,腾讯,网易等。这篇文章主要是介绍如何提高运行在 Linux或UNIX系统的Nginx Web服务器的安全性。 默认配置文件和Nginx端口 /usr/local/nginx/conf/ – Nginx配置文件目录,/usr/local/nginx/conf/nginx.conf是主配置文件 /usr/local/nginx/html/ – 默认网站文件位置 /usr/local/nginx/logs/ – 默认日志文件位置 Nginx HTTP默认端口 : TCP 80 Nginx HTTPS默认端口: TCP 443 你可以使用以下命令来测试Nginx配置文件准确性。 /usr/local/nginx/sbin/nginx -t 将会输出: the configuration file /usr/local/nginx/conf/nginx.conf syntax is ok configuration file /usr/local/nginx/conf/nginx.conf test is successful 执行以下命令来重新加载配置文件。 /usr/local/nginx/sbin/nginx -s reload 执行以下命令来停止服务器。 /usr/local/nginx/sbin/nginx -s stop 一、配置SELinux 注意:对于云服务器 ECS,参阅 ECS 使用须知 ,基于兼容性、稳定性考虑,请勿开启 SELinux。 安全增强型 Linux(SELinux)是一个Linux内核的功能,它提供支持访问控制的安全政策保护机制。它可以防御大部分攻击。下面我们来看如何启动基于centos/RHEL系统的SELinux。 安装SELinux rpm -qa | grep selinux libselinux-1.23.10-2 selinux-policy-targeted-1.23.16-6 如果没有返回任何结果,代表没有安装 SELinux,如果返回了类似上面的结果,则说明系统安装了 SELinux。 布什值锁定 运行命令getsebool -a来锁定系统。 getsebool -a | less getsebool -a | grep off getsebool -a | grep o 二、通过分区挂载允许最少特权 服务器上的网页/html/php文件单独分区。例如,新建一个分区/dev/sda5(第一逻辑分区),并且挂载在/nginx。确保 /nginx是以noexec, nodev and nosetuid的权限挂载。以下是我的/etc/fstab的挂载/nginx的信息: LABEL=/nginx /nginx ext3 defaults,nosuid,noexec,nodev 1 2 注意:你需要使用fdisk和mkfs.ext3命令创建一个新分区。 三、配置/etc/sysctl.conf强化Linux安全 你可以通过编辑/etc/sysctl.conf来控制和配置Linux内核、网络设置。 Avoid a smurf attack net.ipv4.icmp_echo_ignore_broadcasts = 1 Turn on protection for bad icmp error messages net.ipv4.icmp_ignore_bogus_error_responses = 1 Turn on syncookies for SYN flood attack protection net.ipv4.tcp_syncookies = 1 Turn on and log spoofed, source routed, and redirect packets net.ipv4.conf.all.log_martians = 1 net.ipv4.conf.default.log_martians = 1 No source routed packets here net.ipv4.conf.all.accept_source_route = 0 net.ipv4.conf.default.accept_source_route = 0 Turn on reverse path filtering net.ipv4.conf.all.rp_filter = 1 net.ipv4.conf.default.rp_filter = 1 Make sure no one can alter the routing tables net.ipv4.conf.all.accept_redirects = 0 net.ipv4.conf.default.accept_redirects = 0 net.ipv4.conf.all.secure_redirects = 0 net.ipv4.conf.default.secure_redirects = 0 Don’t act as a router net.ipv4.ip_forward = 0 net.ipv4.conf.all.send_redirects = 0 net.ipv4.conf.default.send_redirects = 0 Turn on execshild kernel.exec-shield = 1 kernel.randomize_va_space = 1 Tuen IPv6 net.ipv6.conf.default.router_solicitations = 0 net.ipv6.conf.default.accept_ra_rtr_pref = 0 net.ipv6.conf.default.accept_ra_pinfo = 0 net.ipv6.conf.default.accept_ra_defrtr = 0 net.ipv6.conf.default.autoconf = 0 net.ipv6.conf.default.dad_transmits = 0 net.ipv6.conf.default.max_addresses = 1 Optimization for port usefor LBs Increase system file descriptor limit fs.file-max = 65535 Allow for more PIDs (to reduce rollover problems); may break some programs 32768 kernel.pid_max = 65536 Increase system IP port limits net.ipv4.ip_local_port_range = 2000 65000 Increase TCP max buffer size setable using setsockopt() net.ipv4.tcp_rmem = 4096 87380 8388608 net.ipv4.tcp_wmem = 4096 87380 8388608 Increase Linux auto tuning TCP buffer limits min, default, and max number of bytes to use set max to at least 4MB, or higher if you use very high BDP paths Tcp Windows etc net.core.rmem_max = 8388608 net.core.wmem_max = 8388608 net.core.netdev_max_backlog = 5000 net.ipv4.tcp_window_scaling = 1 四、删除所有不需要的Nginx模块 你需要直接通过编译Nginx源代码使模块数量最少化。通过限制只允许web服务器访问模块把风险降到最低。你可以只配置安装nginx你所需要的模块。例如,禁用SSL和autoindex模块你可以执行以下命令: ./configure –without-http_autoindex_module –without-http_ssi_module make make install 通过以下命令来查看当编译nginx服务器时哪个模块能开户或关闭: ./configure –help | less 禁用你用不到的nginx模块。 (可选项)更改nginx版本名称。 编辑文件/http/ngx_http_header_filter_module.c: vi +48 src/http/ngx_http_header_filter_module.c 找到行: static char ngx_http_server_string[] = “Server: nginx” CRLF; static char ngx_http_server_full_string[] = “Server: ” NGINX_VER CRLF; 按照以下行修改: static char ngx_http_server_string[] = “Server: Ninja Web Server” CRLF; static char ngx_http_server_full_string[] = “Server: Ninja Web Server” CRLF; 保存并关闭文件。现在你可以编辑服务器了。增加以下代码到nginx.conf文件来关闭nginx版本号的显示。 server_tokens off 五、使用mod_security(只适合后端Apache服务器) mod_security为Apache提供一个应用程序级的防火墙。为后端Apache Web服务器安装mod_security,这会阻止很多注入式攻击。 六、安装SELinux策略以强化Nginx Web服务器 默认的SELinux不会保护Nginx Web服务器,但是你可以安装和编译保护软件。 1、安装编译SELinux所需环境支持 yum -y install selinux-policy-targeted selinux-policy-devel 2、下载SELinux策略以强化Nginx Web服务器。 cd /opt wget ‘http://downloads.sourceforge.net/project/selinuxnginx/se-ngix_1_0_10.tar.gz?use_mirror=nchc’ 3、解压文件 tar -zxvf se-ngix_1_0_10.tar.gz 4、编译文件 cd se-ngix_1_0_10/nginx make 将会输出如下: Compiling targeted nginx module /usr/bin/checkmodule: loading policy configuration from tmp/nginx.tmp /usr/bin/checkmodule: policy configuration loaded /usr/bin/checkmodule: writing binary representation (version 6) to tmp/nginx.mod Creating targeted nginx.pp policy package rm tmp/nginx.mod.fc tmp/nginx.mod 5、安装生成的nginx.pp SELinux模块: /usr/sbin/semodule -i nginx.pp 七、基于Iptables防火墙的限制 下面的防火墙脚本阻止任何除了允许: 来自HTTP(TCP端口80)的请求 来自ICMP ping的请求 ntp(端口123)的请求输出 smtp(TCP端口25)的请求输出 #!/bin/bash IPT=”/sbin/iptables” IPS Get server public ip SERVER_IP=$(ifconfig eth0 | grep ‘inet addr:’ | awk -F’inet addr:’ ‘{ print $2}’ | awk ‘{ print $1}’) LB1_IP=”204.54.1.1″ LB2_IP=”204.54.1.2″ Do some smart logic so that we can use damm script on LB2 too OTHER_LB=”" SERVER_IP=”" [[ "$SERVER_IP" == "$LB1_IP" ]] && OTHER_LB=”$LB2_IP” || OTHER_LB=”$LB1_IP” [[ "$OTHER_LB" == "$LB2_IP" ]] && OPP_LB=”$LB1_IP” || OPP_LB=”$LB2_IP” IPs PUB_SSH_ONLY=”122.xx.yy.zz/29″ FILES BLOCKED_IP_TDB=/root/.fw/blocked.ip.txt SPOOFIP=”127.0.0.0/8 192.168.0.0/16 172.16.0.0/12 10.0.0.0/8 169.254.0.0/16 0.0.0.0/8 240.0.0.0/4 255.255.255.255/32 168.254.0.0/16 224.0.0.0/4 240.0.0.0/5 248.0.0.0/5 192.0.2.0/24″ BADIPS=$( [[ -f ${BLOCKED_IP_TDB} ]] && egrep -v “^#|^$” ${BLOCKED_IP_TDB}) Interfaces PUB_IF=”eth0″ # public interface LO_IF=”lo” # loopback VPN_IF=”eth1″ # vpn / private net start firewall echo “Setting LB1 $(hostname) Firewall…” DROP and close everything $IPT -P INPUT DROP $IPT -P OUTPUT DROP $IPT -P FORWARD DROP Unlimited lo access $IPT -A INPUT -i ${LO_IF} -j ACCEPT $IPT -A OUTPUT -o ${LO_IF} -j ACCEPT Unlimited vpn / pnet access $IPT -A INPUT -i ${VPN_IF} -j ACCEPT $IPT -A OUTPUT -o ${VPN_IF} -j ACCEPT Drop sync $IPT -A INPUT -i ${PUB_IF} -p tcp ! –syn -m state –state NEW -j DROP Drop Fragments $IPT -A INPUT -i ${PUB_IF} -f -j DROP $IPT -A INPUT -i ${PUB_IF} -p tcp –tcp-flags ALL FIN,URG,PSH -j DROP $IPT -A INPUT -i ${PUB_IF} -p tcp –tcp-flags ALL ALL -j DROP Drop NULL packets $IPT -A INPUT -i ${PUB_IF} -p tcp –tcp-flags ALL NONE -m limit –limit 5/m –limit-burst 7 -j LOG –log-prefix ” NULL Packets “ $IPT -A INPUT -i ${PUB_IF} -p tcp –tcp-flags ALL NONE -j DROP $IPT -A INPUT -i ${PUB_IF} -p tcp –tcp-flags SYN,RST SYN,RST -j DROP Drop XMAS $IPT -A INPUT -i ${PUB_IF} -p tcp –tcp-flags SYN,FIN SYN,FIN -m limit –limit 5/m –limit-burst 7 -j LOG –log-prefix ” XMAS Packets “ $IPT -A INPUT -i ${PUB_IF} -p tcp –tcp-flags SYN,FIN SYN,FIN -j DROP Drop FIN packet scans $IPT -A INPUT -i ${PUB_IF} -p tcp –tcp-flags FIN,ACK FIN -m limit –limit 5/m –limit-burst 7 -j LOG –log-prefix ” Fin Packets Scan “ $IPT -A INPUT -i ${PUB_IF} -p tcp –tcp-flags FIN,ACK FIN -j DROP $IPT -A INPUT -i ${PUB_IF} -p tcp –tcp-flags ALL SYN,RST,ACK,FIN,URG -j DROP Log and get rid of broadcast / multicast and invalid $IPT -A INPUT -i ${PUB_IF} -m pkttype –pkt-type broadcast -j LOG –log-prefix ” Broadcast “ $IPT -A INPUT -i ${PUB_IF} -m pkttype –pkt-type broadcast -j DROP $IPT -A INPUT -i ${PUB_IF} -m pkttype –pkt-type multicast -j LOG –log-prefix ” Multicast “ $IPT -A INPUT -i ${PUB_IF} -m pkttype –pkt-type multicast -j DROP $IPT -A INPUT -i ${PUB_IF} -m state –state INVALID -j LOG –log-prefix ” Invalid “ $IPT -A INPUT -i ${PUB_IF} -m state –state INVALID -j DROP Log and block spoofed ips $IPT -N spooflist for ipblock in $SPOOFIP do $IPT -A spooflist -i ${PUB_IF} -s $ipblock -j LOG –log-prefix ” SPOOF List Block “ $IPT -A spooflist -i ${PUB_IF} -s $ipblock -j DROP done $IPT -I INPUT -j spooflist $IPT -I OUTPUT -j spooflist $IPT -I FORWARD -j spooflist Allow ssh only from selected public ips for ip in ${PUB_SSH_ONLY} do $IPT -A INPUT -i ${PUB_IF} -s ${ip} -p tcp -d ${SERVER_IP} –destination-port 22 -j ACCEPT $IPT -A OUTPUT -o ${PUB_IF} -d ${ip} -p tcp -s ${SERVER_IP} –sport 22 -j ACCEPT done allow incoming ICMP ping pong stuff $IPT -A INPUT -i ${PUB_IF} -p icmp –icmp-type 8 -s 0/0 -m state –state NEW,ESTABLISHED,RELATED -m limit –limit 30/sec -j ACCEPT $IPT -A OUTPUT -o ${PUB_IF} -p icmp –icmp-type 0 -d 0/0 -m state –state ESTABLISHED,RELATED -j ACCEPT allow incoming HTTP port 80 $IPT -A INPUT -i ${PUB_IF} -p tcp -s 0/0 –sport 1024:65535 –dport 80 -m state –state NEW,ESTABLISHED -j ACCEPT $IPT -A OUTPUT -o ${PUB_IF} -p tcp –sport 80 -d 0/0 –dport 1024:65535 -m state –state ESTABLISHED -j ACCEPT allow outgoing ntp $IPT -A OUTPUT -o ${PUB_IF} -p udp –dport 123 -m state –state NEW,ESTABLISHED -j ACCEPT $IPT -A INPUT -i ${PUB_IF} -p udp –sport 123 -m state –state ESTABLISHED -j ACCEPT allow outgoing smtp $IPT -A OUTPUT -o ${PUB_IF} -p tcp –dport 25 -m state –state NEW,ESTABLISHED -j ACCEPT $IPT -A INPUT -i ${PUB_IF} -p tcp –sport 25 -m state –state ESTABLISHED -j ACCEPT add your other rules here ####################### drop and log everything else $IPT -A INPUT -m limit –limit 5/m –limit-burst 7 -j LOG –log-prefix ” DEFAULT DROP “ $IPT -A INPUT -j DROP exit 0 八、控制缓冲区溢出攻击 编辑nginx.conf,为所有客户端设置缓冲区的大小限制。 vi /usr/local/nginx/conf/nginx.conf 编辑和设置所有客户端缓冲区的大小限制如下: Start: Size Limits & Buffer Overflows client_body_buffer_size 1K; client_header_buffer_size 1k; client_max_body_size 1k; large_client_header_buffers 2 1k; END: Size Limits & Buffer Overflows 解释: 1、client_body_buffer_size 1k-(默认8k或16k)这个指令可以指定连接请求实体的缓冲区大小。如果连接请求超过缓存区指定的值,那么这些请求实体的整体或部分将尝试写入一个临时文件。 2、client_header_buffer_size 1k-指令指定客户端请求头部的缓冲区大小。绝大多数情况下一个请求头不会大于1k,不过如果有来自于wap客户端的较大的cookie它可能会大于 1k,Nginx将分配给它一个更大的缓冲区,这个值可以在large_client_header_buffers里面设置。 3、client_max_body_size 1k-指令指定允许客户端连接的最大请求实体大小,它出现在请求头部的Content-Length字段。 如果请求大于指定的值,客户端将收到一个”Request Entity Too Large” (413)错误。记住,浏览器并不知道怎样显示这个错误。 4、large_client_header_buffers-指定客户端一些比较大的请求头使用的缓冲区数量和大小。请求字段不能大于一个缓冲区大小,如果客户端发送一个比较大的头,nginx将返回”Request URI too large” (414) 同样,请求的头部最长字段不能大于一个缓冲区,否则服务器将返回”Bad request” (400)。缓冲区只在需求时分开。默认一个缓冲区大小为操作系统中分页文件大小,通常是4k或8k,如果一个连接请求最终将状态转换为keep- alive,它所占用的缓冲区将被释放。 你还需要控制超时来提高服务器性能并与客户端断开连接。按照如下编辑: Start: Timeouts client_body_timeout 10; client_header_timeout 10; keepalive_timeout 5 5; send_timeout 10; End: Timeouts 1、client_body_timeout 10;-指令指定读取请求实体的超时时间。这里的超时是指一个请求实体没有进入读取步骤,如果连接超过这个时间而客户端没有任何响应,Nginx将返回一个”Request time out” (408)错误。 2、client_header_timeout 10;-指令指定读取客户端请求头标题的超时时间。这里的超时是指一个请求头没有进入读取步骤,如果连接超过这个时间而客户端没有任何响应,Nginx将返回一个”Request time out” (408)错误。 3、keepalive_timeout 5 5; – 参数的第一个值指定了客户端与服务器长连接的超时时间,超过这个时间,服务器将关闭连接。参数的第二个值(可选)指定了应答头中Keep-Alive: timeout=time的time值,这个值可以使一些浏览器知道什么时候关闭连接,以便服务器不用重复关闭,如果不指定这个参数,nginx不会在应 答头中发送Keep-Alive信息。(但这并不是指怎样将一个连接“Keep-Alive”)参数的这两个值可以不相同。 4、send_timeout 10; 指令指定了发送给客户端应答后的超时时间,Timeout是指没有进入完整established状态,只完成了两次握手,如果超过这个时间客户端没有任何响应,nginx将关闭连接。 九、控制并发连接 你可以使用NginxHttpLimitZone模块来限制指定的会话或者一个IP地址的特殊情况下的并发连接。编辑nginx.conf: Directive describes the zone, in which the session states are stored i.e. store in slimits. 1m can handle 32000 sessions with 32 bytes/session, set to 5m x 32000 session limit_zone slimits $binary_remote_addr 5m; Control maximum number of simultaneous connections for one session i.e. restricts the amount of connections from a single ip address limit_conn slimits 5; 上面表示限制每个远程IP地址的客户端同时打开连接不能超过5个。 十、只允许我们的域名的访问 如果机器人只是随机扫描服务器的所有域名,那拒绝这个请求。你必须允许配置的虚拟域或反向代理请求。你不必使用IP地址来拒绝。 Only requests to our Host are allowed i.e. nixcraft.in, images.nixcraft.in and www.nixcraft.in if ($host !~ ^(nixcraft.in|www.nixcraft.in|images.nixcraft.in)$ ) { return 444; } 十一、限制可用的请求方法 GET和POST是互联网上最常用的方法。 Web服务器的方法被定义在RFC 2616。如果Web服务器不要求启用所有可用的方法,它们应该被禁用。下面的指令将过滤只允许GET,HEAD和POST方法: Only allow these request methods if ($request_method !~ ^(GET|HEAD|POST)$ ) { return 444; } Do not accept DELETE, SEARCH and other methods 更多关于HTTP方法的介绍 GET方法是用来请求,如文件http://www.moqifei.com/index.php。 HEAD方法是一样的,除非该服务器的GET请求无法返回消息体。 POST方法可能涉及到很多东西,如储存或更新数据,或订购产品,或通过提交表单发送电子邮件。这通常是使用服务器端处理,如PHP,Perl和Python等脚本。如果你要上传的文件和在服务器处理数据,你必须使用这个方法。 十二、如何拒绝一些User-Agents? 你可以很容易地阻止User-Agents,如扫描器,机器人以及滥用你服务器的垃圾邮件发送者。 Block download agents if ($http_user_agent ~* LWP::Simple|BBBike|wget) { return 403; } 阻止Soso和有道的机器人: Block some robots if ($http_user_agent ~* Sosospider|YodaoBot) { return 403; } 十三、如何防止图片盗链 图片或HTML盗链的意思是有人直接用你网站的图片地址来显示在他的网站上。最终的结果,你需要支付额外的宽带费用。这通常是在论坛和博客。我强烈建议您封锁,并阻止盗链行为。 Stop deep linking or hot linking location /images/ { valid_referers none blocked www.example.com example.com; if ($invalid_referer) { return 403; } } 例如:重定向并显示指定图片 valid_referers blocked www.example.com example.com; if ($invalid_referer) { rewrite ^/images/uploads.*.(gif|jpg|jpeg|png)$ http://www.examples.com/banned.jpg last } 十四、目录限制 你可以对指定的目录设置访问权限。所有的网站目录应该一一的配置,只允许必须的目录访问权限。 通过IP地址限制访问 你可以通过IP地址来限制访问目录/admin/: location /docs/ { block one workstation deny 192.168.1.1; allow anyone in 192.168.1.0/24 allow 192.168.1.0/24; drop rest of the world deny all; } 通过密码保护目录 首先创建密码文件并增加“user”用户: mkdir /usr/local/nginx/conf/.htpasswd/ htpasswd -c /usr/local/nginx/conf/.htpasswd/passwd user 编辑nginx.conf,加入需要保护的目录: Password Protect /personal-images/ and /delta/ directories location ~ /(personal-images/.|delta/.) { auth_basic “Restricted”; auth_basic_user_file /usr/local/nginx/conf/.htpasswd/passwd; } 一旦密码文件已经生成,你也可以用以下的命令来增加允许访问的用户: htpasswd -s /usr/local/nginx/conf/.htpasswd/passwd userName 十五、Nginx SSL配置 HTTP是一个纯文本协议,它是开放的被动监测。你应该使用SSL来加密你的用户内容。 创建SSL证书 执行以下命令: cd /usr/local/nginx/conf openssl genrsa -des3 -out server.key 1024 openssl req -new -key server.key -out server.csr cp server.key server.key.org openssl rsa -in server.key.org -out server.key openssl x509 -req -days 365 -in server.csr -signkey server.key -out server.crt 编辑nginx.conf并按如下来更新: server { server_name example.com; listen 443; ssl on; ssl_certificate /usr/local/nginx/conf/server.crt; ssl_certificate_key /usr/local/nginx/conf/server.key; access_log /usr/local/nginx/logs/ssl.access.log; error_log /usr/local/nginx/logs/ssl.error.log; } 重启nginx: /usr/local/nginx/sbin/nginx -s reload 十六、Nginx与PHP安全建议 PHP是流行的服务器端脚本语言之一。如下编辑/etc/php.ini文件: Disallow dangerous functions disable_functions = phpinfo, system, mail, exec Try to limit resources Maximum execution time of each script, in seconds max_execution_time = 30 Maximum amount of time each script may spend parsing request data max_input_time = 60 Maximum amount of memory a script may consume (8MB) memory_limit = 8M Maximum size of POST data that PHP will accept. post_max_size = 8M Whether to allow HTTP file uploads. file_uploads = Off Maximum allowed size for uploaded files. upload_max_filesize = 2M Do not expose PHP error messages to external users display_errors = Off Turn on safe mode safe_mode = On Only allow access to executables in isolated directory safe_mode_exec_dir = php-required-executables-path Limit external access to PHP environment safemode_allowed_env_vars = PHP Restrict PHP information leakage expose_php = Off Log all errors log_errors = On Do not register globals for input data register_globals = Off Minimize allowable PHP post size post_max_size = 1K Ensure PHP redirects appropriately cgi.force_redirect = 0 Disallow uploading unless necessary file_uploads = Off Enable SQL safe mode sql.safe_mode = On Avoid Opening remote files allow_url_fopen = Off 十七、如果可能让Nginx运行在一个chroot监狱 把nginx放在一个chroot监狱以减小潜在的非法进入其它目录。你可以使用传统的与nginx一起安装的chroot。如果可能,那使用FreeBSD jails,Xen,OpenVZ虚拟化的容器概念。 十八、在防火墙级限制每个IP的连接数 网络服务器必须监视连接和每秒连接限制。PF和Iptales都能够在进入你的nginx服务器之前阻止最终用户的访问。 Linux Iptables:限制每次Nginx连接数 下面的例子会阻止来自一个IP的60秒钟内超过15个连接端口80的连接数。 /sbin/iptables -A INPUT -p tcp –dport 80 -i eth0 -m state –state NEW -m recent –set /sbin/iptables -A INPUT -p tcp –dport 80 -i eth0 -m state –state NEW -m recent –update –seconds 60 –hitcount 15 -j DROP service iptables save 请根据你的具体情况来设置限制的连接数。 十九:配置操作系统保护Web服务器 像以上介绍的启动SELinux.正确设置/nginx文档根目录的权限。Nginx以用户nginx运行。但是根目录(/nginx或者/usr /local/nginx/html)不应该设置属于用户nginx或对用户nginx可写。找出错误权限的文件可以使用如下命令: find /nginx -user nginx find /usr/local/nginx/html -user nginx 确保你更所有权为root或其它用户,一个典型的权限设置 /usr/local/nginx/html/ ls -l /usr/local/nginx/html/ 示例输出: -rw-r–r– 1 root root 925 Jan 3 00:50 error4xx.html -rw-r–r– 1 root root 52 Jan 3 10:00 error5xx.html -rw-r–r– 1 root root 134 Jan 3 00:52 index.html 你必须删除由vi或其它文本编辑器创建的备份文件: find /nginx -name ‘.?’ -not -name .ht -or -name ‘~’ -or -name ‘.bak’ -or -name ‘.old*’ find /usr/local/nginx/html/ -name ‘.?’ -not -name .ht -or -name ‘~’ -or -name ‘.bak’ -or -name ‘.old*’ 通过find命令的-delete选项来删除这些文件。 二十、限制Nginx连接传出 黑客会使用工具如wget下载你服务器本地的文件。使用Iptables从nginx用户来阻止传出连接。ipt_owner模块试图匹配本地产生的数据包的创建者。下面的例子中只允许user用户在外面使用80连接。 /sbin/iptables -A OUTPUT -o eth0 -m owner –uid-owner vivek -p tcp –dport 80 -m state –state NEW,ESTABLISHED -j ACCEPT 通过以上的配置,你的nginx服务器已经非常安全了并可以发布网页。可是,你还应该根据你网站程序查找更多的安全设置资料。例如,wordpress或者第三方程序。

KB小秘书 2019-12-02 02:06:56 0 浏览量 回答数 0

问题

HBase行级事务模型

pandacats 2019-12-20 19:51:58 0 浏览量 回答数 0

问题

为什么要分库分表(设计高并发系统的时候,数据库层面该如何设计)?【Java问答】41期

剑曼红尘 2020-06-19 13:47:21 0 浏览量 回答数 0

问题

最大限度利用 JavaScript 和 Ajax 性能:报错

kun坤 2020-06-05 22:56:50 0 浏览量 回答数 1

回答

详细解答可以参考官方帮助文档 本示例讲解如何在服务端通过PHP代码完成签名,然后通过表单直传数据到OSS。 说明 本示例无法实现分片上传与断点续传。 背景 采用JavaScript客户端直接签名(参见JavaScript客户端签名直传)有一个严重的安全隐患:OSS AccessKey暴露在前端页面,这是非常不安全的做法。因此,OSS提供了服务端签名后直传的方案。 Demo 您可以通过样例体验服务端签名后直传效果:PC浏览器测试样例 原理介绍 服务端签名后直传的逻辑图如下: 流程如下: 用户发送上传Policy请求到应用服务器。 应用服务器返回上传Policy和签名给用户。 用户使用Plupload直接上传数据到OSS。 步骤 1:下载并安装Plugload Plupload是一款简单易用且功能强大的文件上传工具, 支持多种上传方式,包括html5、flash、silverlight,、html4。它会智能检测当前环境,选择最适合的上传方式,并且会优先采用Html5方式。请参见Plupload官网进行下载和安装。 步骤 2:下载应用服务器代码 PHP:下载地址 Java:下载地址 Python:下载地址 Go:下载地址 步骤 3:修改配置文件 本示例采用PHP编写。将下载包解压后,修改以下文件: php/get.php文件:$id= '<yourAccessKeyId>'; $key= '<yourAccessKeySecret>'; $host = 'http://post-test.oss-cn-hangzhou.aliyuncs.com $id:您的AccessKeyId $key:您的AessKeySecret $host:格式为BucketName.Endpoint,例如post-test.oss-cn-hangzhou.aliyuncs.com 说明 关于Endpoint的介绍,请参见Endpoint(访问域名)。 upload.js文件 将变量severUrl改成服务器部署的地址,例如http://abc.com:8080/oss-h5-upload-js-php/get.php。 步骤 4:设置CORS HTML表单直接上传到OSS会产生跨域请求。为了浏览安全,需要为Bucket设置跨域规则(CORS),支持Post方法。 具体操作步骤请参见设置跨域访问。设置如下图所示: 说明 在低版本IE浏览器,Plupload会以Flash方式执行。您需要设置crossdomain.xml ,设置方法请参见OSS Web直传—使用Flash上传。 步骤 5:体验服务端签名后直传 将应用服务器代码zip包解压到Web根目录下。 在Web浏览器中输入<Web应用服务器地址>/oss-h5-upload-js-php/index.html,例如http://abc.com:8080/oss-h5-upload-js-php/index.html。 选择一个或多个文件进行上传。 上传成功后,通过控制台查看上传结果。 核心代码解析 设置成随机文件名 如果想在上传时固定设置成随机文件名,后缀保持跟客户端文件一致,可以将函数改为:function check_object_radio() { g_object_name_type = 'random_name'; } 设置成用户的文件名 如果想在上传时固定设置成用户的文件名,可以将函数改为:function check_object_radio() { g_object_name_type = 'local_name'; } 设置上传目录 上传的目录由服务端(即PHP)指定, 每个客户端只能上传到指定的目录,实现安全隔离。下面的代码是将上传目录改成abc/,注意目录必须以正斜线(/)结尾。$dir = 'abc/'; 设置上传过滤条件 您可以利用Plupload的属性filters设置上传的过滤条件,如设置只能上传图片、上传文件的大小、不能有重复上传等。var uploader = new plupload.Uploader({ …… filters: { mime_types : [ //只允许上传图片和zip文件 { title : "Image files", extensions : "jpg,gif,png,bmp" }, { title : "Zip files", extensions : "zip" } ], max_file_size : '400kb', //最大只能上传400KB的文件 prevent_duplicates : true //不允许选取重复文件 }, mime_types:限制上传的文件后缀 max_file_size:限制上传的文件大小 prevent_duplicates:限制不能重复上传 说明 filters过滤条件不是必须的。如果不想设置过滤条件,只要把该项注释即可。 获取上传后的文件名 如果要知道文件上传成功后的文件名,可以用Plupload调用FileUploaded事件获取,如下所示:FileUploaded: function(up, file, info) { if (info.status == 200) { document.getElementById(file.id).getElementsByTagName('b')[0].innerHTML = 'upload to oss success, object name:' + get_uploaded_object_name(file.name); } else { document.getElementById(file.id).getElementsByTagName('b')[0].innerHTML = info.response; } }可以利用如下函数,得到上传到OSS的文件名,其中file.name记录了上传本地文件的名称。get_uploaded_object_name(file.name) 上传签名 JavaScript可以从服务端获取policyBase64、accessid、signature这三个变量,获取这三个变量的核心代码如下:phpUrl = './php/get.php' xmlhttp.open( "GET", phpUrl, false ); xmlhttp.send( null ); var obj = eval ("(" + xmlhttp.responseText+ ")"); host = obj['host'] policyBase64 = obj['policy'] accessid = obj['accessid'] signature = obj['signature'] expire = parseInt(obj['expire']) key = obj['dir'] xmlhttp.responseText解析如下: 说明 以下仅为示例,并不要求必须是相同的格式,但是必须有accessid、policy、signature这三个值。 {"accessid":"6MKOqxGiGU4AUk44", "host":"http://post-test.oss-cn-hangzhou.aliyuncs.com", "policy":"eyJleHBpcmF0aW9uIjoiMjAxNS0xMS0wNVQyMDoyMzoyM1oiLCJjxb25kaXRpb25zIjpbWyJjcb250ZW50LWxlbmd0aC1yYW5nZSIsMCwxMDQ4NTc2MDAwXSxbInN0YXJ0cy13aXRoIiwiJGtleSIsInVzZXItZGlyXC8iXV19", "signature":"I2u57FWjTKqX/AE6doIdyff151E=", "expire":1446726203,"dir":"user-dir/"} accessid:用户请求的accessid。 host:用户要往哪个域名发送上传请求。 policy:用户表单上传的策略(Policy),是经过base64编码过的字符串。 signature:对变量policy签名后的字符串。 expire:上传策略失效时间,在PolicyText里指定。在失效时间之前,都可以利用此Policy上传文件,所以没有必要每次上传都去服务端获取签名。 说明 为了减少服务端的压力,设计思路是:初始化上传时,每上传一个文件后,获取一次签名。然后再上传时,比较当前时间与签名时间,看签名时间是否失效。如果失效了,就重新获取一次签名,如果没有失效,就使用之前的签名。这里就用到了变量expire,核心代码如下:now = timestamp = Date.parse(new Date()) / 1000; [color=#000000]//可以判断当前expire是否超过了当前时间,如果超过了当前时间,就重新取一次签名,缓冲时间为3[/color] if (expire < now + 3) {    .....    phpUrl = './php/get.php'    xmlhttp.open( "GET", phpUrl, false );    xmlhttp.send( null );    ...... } return . 解析Policy的内容如下:{"expiration":"2015-11-05T20:23:23Z", "conditions":[["content-length-range",0,1048576000], ["starts-with","$key","user-dir/"]] 说明 Policy的详细信息请参见Policy基本元素。 上面Policy中增加了starts-with,用来指定此次上传的文件名必须以user-dir开头,用户可自行指定此字符串。增加starts-with的原因是:在很多场景下,一个应用对应一个Bucket,为了防止数字覆盖,每个用户上传到OSS的文件都可以有特定的前缀。这样就存在一个问题,用户获取到这个Policy后,在失效期内都能修改上传前缀,从而上传到别人的目录下。为了解决这个问题,可以设置应用服务器在上传时就指定用户上传的文件必须是某个前缀。这样如果用户获取到了Policy也没有办法上传到别人的前缀上,从而保证了数据的安全性。 总结 本示例中,web端向服务端请求签名,然后直接上传,不会对服务端产生压力,而且安全可靠。但是这个示例有个问题,就是用户上传了多少文件,上传了什么文件,服务端并不能马上知道,如果想实时了解用户上传了什么文件,可以采用服务端签名直传并设置上传回调。

2019-12-01 23:13:27 0 浏览量 回答数 0

回答

详细解答可以参考官方帮助文档 本示例讲解如何在服务端通过PHP代码完成签名,然后通过表单直传数据到OSS。 说明 本示例无法实现分片上传与断点续传。 背景 采用JavaScript客户端直接签名(参见JavaScript客户端签名直传)有一个严重的安全隐患:OSS AccessKey暴露在前端页面,这是非常不安全的做法。因此,OSS提供了服务端签名后直传的方案。 Demo 您可以通过样例体验服务端签名后直传效果:PC浏览器测试样例 原理介绍 服务端签名后直传的逻辑图如下: 流程如下: 用户发送上传Policy请求到应用服务器。 应用服务器返回上传Policy和签名给用户。 用户使用Plupload直接上传数据到OSS。 步骤 1:下载并安装Plugload Plupload是一款简单易用且功能强大的文件上传工具, 支持多种上传方式,包括html5、flash、silverlight,、html4。它会智能检测当前环境,选择最适合的上传方式,并且会优先采用Html5方式。请参见Plupload官网进行下载和安装。 步骤 2:下载应用服务器代码 PHP:下载地址 Java:下载地址 Python:下载地址 Go:下载地址 步骤 3:修改配置文件 本示例采用PHP编写。将下载包解压后,修改以下文件: php/get.php文件:$id= '<yourAccessKeyId>'; $key= '<yourAccessKeySecret>'; $host = 'http://post-test.oss-cn-hangzhou.aliyuncs.com $id:您的AccessKeyId $key:您的AessKeySecret $host:格式为BucketName.Endpoint,例如post-test.oss-cn-hangzhou.aliyuncs.com 说明 关于Endpoint的介绍,请参见Endpoint(访问域名)。 upload.js文件 将变量severUrl改成服务器部署的地址,例如http://abc.com:8080/oss-h5-upload-js-php/get.php。 步骤 4:设置CORS HTML表单直接上传到OSS会产生跨域请求。为了浏览安全,需要为Bucket设置跨域规则(CORS),支持Post方法。 具体操作步骤请参见设置跨域访问。设置如下图所示: 说明 在低版本IE浏览器,Plupload会以Flash方式执行。您需要设置crossdomain.xml ,设置方法请参见OSS Web直传—使用Flash上传。 步骤 5:体验服务端签名后直传 将应用服务器代码zip包解压到Web根目录下。 在Web浏览器中输入<Web应用服务器地址>/oss-h5-upload-js-php/index.html,例如http://abc.com:8080/oss-h5-upload-js-php/index.html。 选择一个或多个文件进行上传。 上传成功后,通过控制台查看上传结果。 核心代码解析 设置成随机文件名 如果想在上传时固定设置成随机文件名,后缀保持跟客户端文件一致,可以将函数改为:function check_object_radio() { g_object_name_type = 'random_name'; } 设置成用户的文件名 如果想在上传时固定设置成用户的文件名,可以将函数改为:function check_object_radio() { g_object_name_type = 'local_name'; } 设置上传目录 上传的目录由服务端(即PHP)指定, 每个客户端只能上传到指定的目录,实现安全隔离。下面的代码是将上传目录改成abc/,注意目录必须以正斜线(/)结尾。$dir = 'abc/'; 设置上传过滤条件 您可以利用Plupload的属性filters设置上传的过滤条件,如设置只能上传图片、上传文件的大小、不能有重复上传等。var uploader = new plupload.Uploader({ …… filters: { mime_types : [ //只允许上传图片和zip文件 { title : "Image files", extensions : "jpg,gif,png,bmp" }, { title : "Zip files", extensions : "zip" } ], max_file_size : '400kb', //最大只能上传400KB的文件 prevent_duplicates : true //不允许选取重复文件 }, mime_types:限制上传的文件后缀 max_file_size:限制上传的文件大小 prevent_duplicates:限制不能重复上传 说明 filters过滤条件不是必须的。如果不想设置过滤条件,只要把该项注释即可。 获取上传后的文件名 如果要知道文件上传成功后的文件名,可以用Plupload调用FileUploaded事件获取,如下所示:FileUploaded: function(up, file, info) { if (info.status == 200) { document.getElementById(file.id).getElementsByTagName('b')[0].innerHTML = 'upload to oss success, object name:' + get_uploaded_object_name(file.name); } else { document.getElementById(file.id).getElementsByTagName('b')[0].innerHTML = info.response; } }可以利用如下函数,得到上传到OSS的文件名,其中file.name记录了上传本地文件的名称。get_uploaded_object_name(file.name) 上传签名 JavaScript可以从服务端获取policyBase64、accessid、signature这三个变量,获取这三个变量的核心代码如下:phpUrl = './php/get.php' xmlhttp.open( "GET", phpUrl, false ); xmlhttp.send( null ); var obj = eval ("(" + xmlhttp.responseText+ ")"); host = obj['host'] policyBase64 = obj['policy'] accessid = obj['accessid'] signature = obj['signature'] expire = parseInt(obj['expire']) key = obj['dir'] xmlhttp.responseText解析如下: 说明 以下仅为示例,并不要求必须是相同的格式,但是必须有accessid、policy、signature这三个值。 {"accessid":"6MKOqxGiGU4AUk44", "host":"http://post-test.oss-cn-hangzhou.aliyuncs.com", "policy":"eyJleHBpcmF0aW9uIjoiMjAxNS0xMS0wNVQyMDoyMzoyM1oiLCJjxb25kaXRpb25zIjpbWyJjcb250ZW50LWxlbmd0aC1yYW5nZSIsMCwxMDQ4NTc2MDAwXSxbInN0YXJ0cy13aXRoIiwiJGtleSIsInVzZXItZGlyXC8iXV19", "signature":"I2u57FWjTKqX/AE6doIdyff151E=", "expire":1446726203,"dir":"user-dir/"} accessid:用户请求的accessid。 host:用户要往哪个域名发送上传请求。 policy:用户表单上传的策略(Policy),是经过base64编码过的字符串。 signature:对变量policy签名后的字符串。 expire:上传策略失效时间,在PolicyText里指定。在失效时间之前,都可以利用此Policy上传文件,所以没有必要每次上传都去服务端获取签名。 说明 为了减少服务端的压力,设计思路是:初始化上传时,每上传一个文件后,获取一次签名。然后再上传时,比较当前时间与签名时间,看签名时间是否失效。如果失效了,就重新获取一次签名,如果没有失效,就使用之前的签名。这里就用到了变量expire,核心代码如下:now = timestamp = Date.parse(new Date()) / 1000; [color=#000000]//可以判断当前expire是否超过了当前时间,如果超过了当前时间,就重新取一次签名,缓冲时间为3[/color] if (expire < now + 3) {    .....    phpUrl = './php/get.php'    xmlhttp.open( "GET", phpUrl, false );    xmlhttp.send( null );    ...... } return . 解析Policy的内容如下:{"expiration":"2015-11-05T20:23:23Z", "conditions":[["content-length-range",0,1048576000], ["starts-with","$key","user-dir/"]] 说明 Policy的详细信息请参见Policy基本元素。 上面Policy中增加了starts-with,用来指定此次上传的文件名必须以user-dir开头,用户可自行指定此字符串。增加starts-with的原因是:在很多场景下,一个应用对应一个Bucket,为了防止数字覆盖,每个用户上传到OSS的文件都可以有特定的前缀。这样就存在一个问题,用户获取到这个Policy后,在失效期内都能修改上传前缀,从而上传到别人的目录下。为了解决这个问题,可以设置应用服务器在上传时就指定用户上传的文件必须是某个前缀。这样如果用户获取到了Policy也没有办法上传到别人的前缀上,从而保证了数据的安全性。 总结 本示例中,web端向服务端请求签名,然后直接上传,不会对服务端产生压力,而且安全可靠。但是这个示例有个问题,就是用户上传了多少文件,上传了什么文件,服务端并不能马上知道,如果想实时了解用户上传了什么文件,可以采用服务端签名直传并设置上传回调。

2019-12-01 23:13:28 0 浏览量 回答数 0

回答

详细解答可以参考官方帮助文档 本示例讲解如何在服务端通过PHP代码完成签名,然后通过表单直传数据到OSS。 说明 本示例无法实现分片上传与断点续传。 背景 采用JavaScript客户端直接签名(参见JavaScript客户端签名直传)有一个严重的安全隐患:OSS AccessKey暴露在前端页面,这是非常不安全的做法。因此,OSS提供了服务端签名后直传的方案。 Demo 您可以通过样例体验服务端签名后直传效果:PC浏览器测试样例 原理介绍 服务端签名后直传的逻辑图如下: 流程如下: 用户发送上传Policy请求到应用服务器。 应用服务器返回上传Policy和签名给用户。 用户使用Plupload直接上传数据到OSS。 步骤 1:下载并安装Plugload Plupload是一款简单易用且功能强大的文件上传工具, 支持多种上传方式,包括html5、flash、silverlight,、html4。它会智能检测当前环境,选择最适合的上传方式,并且会优先采用Html5方式。请参见Plupload官网进行下载和安装。 步骤 2:下载应用服务器代码 PHP:下载地址 Java:下载地址 Python:下载地址 Go:下载地址 步骤 3:修改配置文件 本示例采用PHP编写。将下载包解压后,修改以下文件: php/get.php文件:$id= '<yourAccessKeyId>'; $key= '<yourAccessKeySecret>'; $host = 'http://post-test.oss-cn-hangzhou.aliyuncs.com $id:您的AccessKeyId $key:您的AessKeySecret $host:格式为BucketName.Endpoint,例如post-test.oss-cn-hangzhou.aliyuncs.com 说明 关于Endpoint的介绍,请参见Endpoint(访问域名)。 upload.js文件 将变量severUrl改成服务器部署的地址,例如http://abc.com:8080/oss-h5-upload-js-php/get.php。 步骤 4:设置CORS HTML表单直接上传到OSS会产生跨域请求。为了浏览安全,需要为Bucket设置跨域规则(CORS),支持Post方法。 具体操作步骤请参见设置跨域访问。设置如下图所示: 说明 在低版本IE浏览器,Plupload会以Flash方式执行。您需要设置crossdomain.xml ,设置方法请参见OSS Web直传—使用Flash上传。 步骤 5:体验服务端签名后直传 将应用服务器代码zip包解压到Web根目录下。 在Web浏览器中输入<Web应用服务器地址>/oss-h5-upload-js-php/index.html,例如http://abc.com:8080/oss-h5-upload-js-php/index.html。 选择一个或多个文件进行上传。 上传成功后,通过控制台查看上传结果。 核心代码解析 设置成随机文件名 如果想在上传时固定设置成随机文件名,后缀保持跟客户端文件一致,可以将函数改为:function check_object_radio() { g_object_name_type = 'random_name'; } 设置成用户的文件名 如果想在上传时固定设置成用户的文件名,可以将函数改为:function check_object_radio() { g_object_name_type = 'local_name'; } 设置上传目录 上传的目录由服务端(即PHP)指定, 每个客户端只能上传到指定的目录,实现安全隔离。下面的代码是将上传目录改成abc/,注意目录必须以正斜线(/)结尾。$dir = 'abc/'; 设置上传过滤条件 您可以利用Plupload的属性filters设置上传的过滤条件,如设置只能上传图片、上传文件的大小、不能有重复上传等。var uploader = new plupload.Uploader({ …… filters: { mime_types : [ //只允许上传图片和zip文件 { title : "Image files", extensions : "jpg,gif,png,bmp" }, { title : "Zip files", extensions : "zip" } ], max_file_size : '400kb', //最大只能上传400KB的文件 prevent_duplicates : true //不允许选取重复文件 }, mime_types:限制上传的文件后缀 max_file_size:限制上传的文件大小 prevent_duplicates:限制不能重复上传 说明 filters过滤条件不是必须的。如果不想设置过滤条件,只要把该项注释即可。 获取上传后的文件名 如果要知道文件上传成功后的文件名,可以用Plupload调用FileUploaded事件获取,如下所示:FileUploaded: function(up, file, info) { if (info.status == 200) { document.getElementById(file.id).getElementsByTagName('b')[0].innerHTML = 'upload to oss success, object name:' + get_uploaded_object_name(file.name); } else { document.getElementById(file.id).getElementsByTagName('b')[0].innerHTML = info.response; } }可以利用如下函数,得到上传到OSS的文件名,其中file.name记录了上传本地文件的名称。get_uploaded_object_name(file.name) 上传签名 JavaScript可以从服务端获取policyBase64、accessid、signature这三个变量,获取这三个变量的核心代码如下:phpUrl = './php/get.php' xmlhttp.open( "GET", phpUrl, false ); xmlhttp.send( null ); var obj = eval ("(" + xmlhttp.responseText+ ")"); host = obj['host'] policyBase64 = obj['policy'] accessid = obj['accessid'] signature = obj['signature'] expire = parseInt(obj['expire']) key = obj['dir'] xmlhttp.responseText解析如下: 说明 以下仅为示例,并不要求必须是相同的格式,但是必须有accessid、policy、signature这三个值。 {"accessid":"6MKOqxGiGU4AUk44", "host":"http://post-test.oss-cn-hangzhou.aliyuncs.com", "policy":"eyJleHBpcmF0aW9uIjoiMjAxNS0xMS0wNVQyMDoyMzoyM1oiLCJjxb25kaXRpb25zIjpbWyJjcb250ZW50LWxlbmd0aC1yYW5nZSIsMCwxMDQ4NTc2MDAwXSxbInN0YXJ0cy13aXRoIiwiJGtleSIsInVzZXItZGlyXC8iXV19", "signature":"I2u57FWjTKqX/AE6doIdyff151E=", "expire":1446726203,"dir":"user-dir/"} accessid:用户请求的accessid。 host:用户要往哪个域名发送上传请求。 policy:用户表单上传的策略(Policy),是经过base64编码过的字符串。 signature:对变量policy签名后的字符串。 expire:上传策略失效时间,在PolicyText里指定。在失效时间之前,都可以利用此Policy上传文件,所以没有必要每次上传都去服务端获取签名。 说明 为了减少服务端的压力,设计思路是:初始化上传时,每上传一个文件后,获取一次签名。然后再上传时,比较当前时间与签名时间,看签名时间是否失效。如果失效了,就重新获取一次签名,如果没有失效,就使用之前的签名。这里就用到了变量expire,核心代码如下:now = timestamp = Date.parse(new Date()) / 1000; [color=#000000]//可以判断当前expire是否超过了当前时间,如果超过了当前时间,就重新取一次签名,缓冲时间为3[/color] if (expire < now + 3) {    .....    phpUrl = './php/get.php'    xmlhttp.open( "GET", phpUrl, false );    xmlhttp.send( null );    ...... } return . 解析Policy的内容如下:{"expiration":"2015-11-05T20:23:23Z", "conditions":[["content-length-range",0,1048576000], ["starts-with","$key","user-dir/"]] 说明 Policy的详细信息请参见Policy基本元素。 上面Policy中增加了starts-with,用来指定此次上传的文件名必须以user-dir开头,用户可自行指定此字符串。增加starts-with的原因是:在很多场景下,一个应用对应一个Bucket,为了防止数字覆盖,每个用户上传到OSS的文件都可以有特定的前缀。这样就存在一个问题,用户获取到这个Policy后,在失效期内都能修改上传前缀,从而上传到别人的目录下。为了解决这个问题,可以设置应用服务器在上传时就指定用户上传的文件必须是某个前缀。这样如果用户获取到了Policy也没有办法上传到别人的前缀上,从而保证了数据的安全性。 总结 本示例中,web端向服务端请求签名,然后直接上传,不会对服务端产生压力,而且安全可靠。但是这个示例有个问题,就是用户上传了多少文件,上传了什么文件,服务端并不能马上知道,如果想实时了解用户上传了什么文件,可以采用服务端签名直传并设置上传回调。

2019-12-01 23:13:28 0 浏览量 回答数 0

回答

详细解答可以参考官方帮助文档 本示例讲解如何在服务端通过PHP代码完成签名,然后通过表单直传数据到OSS。 说明 本示例无法实现分片上传与断点续传。 背景 采用JavaScript客户端直接签名(参见JavaScript客户端签名直传)有一个严重的安全隐患:OSS AccessKey暴露在前端页面,这是非常不安全的做法。因此,OSS提供了服务端签名后直传的方案。 Demo 您可以通过样例体验服务端签名后直传效果:PC浏览器测试样例 原理介绍 服务端签名后直传的逻辑图如下: 流程如下: 用户发送上传Policy请求到应用服务器。 应用服务器返回上传Policy和签名给用户。 用户使用Plupload直接上传数据到OSS。 步骤 1:下载并安装Plugload Plupload是一款简单易用且功能强大的文件上传工具, 支持多种上传方式,包括html5、flash、silverlight,、html4。它会智能检测当前环境,选择最适合的上传方式,并且会优先采用Html5方式。请参见Plupload官网进行下载和安装。 步骤 2:下载应用服务器代码 PHP:下载地址 Java:下载地址 Python:下载地址 Go:下载地址 步骤 3:修改配置文件 本示例采用PHP编写。将下载包解压后,修改以下文件: php/get.php文件:$id= '<yourAccessKeyId>'; $key= '<yourAccessKeySecret>'; $host = 'http://post-test.oss-cn-hangzhou.aliyuncs.com $id:您的AccessKeyId $key:您的AessKeySecret $host:格式为BucketName.Endpoint,例如post-test.oss-cn-hangzhou.aliyuncs.com 说明 关于Endpoint的介绍,请参见Endpoint(访问域名)。 upload.js文件 将变量severUrl改成服务器部署的地址,例如http://abc.com:8080/oss-h5-upload-js-php/get.php。 步骤 4:设置CORS HTML表单直接上传到OSS会产生跨域请求。为了浏览安全,需要为Bucket设置跨域规则(CORS),支持Post方法。 具体操作步骤请参见设置跨域访问。设置如下图所示: 说明 在低版本IE浏览器,Plupload会以Flash方式执行。您需要设置crossdomain.xml ,设置方法请参见OSS Web直传—使用Flash上传。 步骤 5:体验服务端签名后直传 将应用服务器代码zip包解压到Web根目录下。 在Web浏览器中输入<Web应用服务器地址>/oss-h5-upload-js-php/index.html,例如http://abc.com:8080/oss-h5-upload-js-php/index.html。 选择一个或多个文件进行上传。 上传成功后,通过控制台查看上传结果。 核心代码解析 设置成随机文件名 如果想在上传时固定设置成随机文件名,后缀保持跟客户端文件一致,可以将函数改为:function check_object_radio() { g_object_name_type = 'random_name'; } 设置成用户的文件名 如果想在上传时固定设置成用户的文件名,可以将函数改为:function check_object_radio() { g_object_name_type = 'local_name'; } 设置上传目录 上传的目录由服务端(即PHP)指定, 每个客户端只能上传到指定的目录,实现安全隔离。下面的代码是将上传目录改成abc/,注意目录必须以正斜线(/)结尾。$dir = 'abc/'; 设置上传过滤条件 您可以利用Plupload的属性filters设置上传的过滤条件,如设置只能上传图片、上传文件的大小、不能有重复上传等。var uploader = new plupload.Uploader({ …… filters: { mime_types : [ //只允许上传图片和zip文件 { title : "Image files", extensions : "jpg,gif,png,bmp" }, { title : "Zip files", extensions : "zip" } ], max_file_size : '400kb', //最大只能上传400KB的文件 prevent_duplicates : true //不允许选取重复文件 }, mime_types:限制上传的文件后缀 max_file_size:限制上传的文件大小 prevent_duplicates:限制不能重复上传 说明 filters过滤条件不是必须的。如果不想设置过滤条件,只要把该项注释即可。 获取上传后的文件名 如果要知道文件上传成功后的文件名,可以用Plupload调用FileUploaded事件获取,如下所示:FileUploaded: function(up, file, info) { if (info.status == 200) { document.getElementById(file.id).getElementsByTagName('b')[0].innerHTML = 'upload to oss success, object name:' + get_uploaded_object_name(file.name); } else { document.getElementById(file.id).getElementsByTagName('b')[0].innerHTML = info.response; } }可以利用如下函数,得到上传到OSS的文件名,其中file.name记录了上传本地文件的名称。get_uploaded_object_name(file.name) 上传签名 JavaScript可以从服务端获取policyBase64、accessid、signature这三个变量,获取这三个变量的核心代码如下:phpUrl = './php/get.php' xmlhttp.open( "GET", phpUrl, false ); xmlhttp.send( null ); var obj = eval ("(" + xmlhttp.responseText+ ")"); host = obj['host'] policyBase64 = obj['policy'] accessid = obj['accessid'] signature = obj['signature'] expire = parseInt(obj['expire']) key = obj['dir'] xmlhttp.responseText解析如下: 说明 以下仅为示例,并不要求必须是相同的格式,但是必须有accessid、policy、signature这三个值。 {"accessid":"6MKOqxGiGU4AUk44", "host":"http://post-test.oss-cn-hangzhou.aliyuncs.com", "policy":"eyJleHBpcmF0aW9uIjoiMjAxNS0xMS0wNVQyMDoyMzoyM1oiLCJjxb25kaXRpb25zIjpbWyJjcb250ZW50LWxlbmd0aC1yYW5nZSIsMCwxMDQ4NTc2MDAwXSxbInN0YXJ0cy13aXRoIiwiJGtleSIsInVzZXItZGlyXC8iXV19", "signature":"I2u57FWjTKqX/AE6doIdyff151E=", "expire":1446726203,"dir":"user-dir/"} accessid:用户请求的accessid。 host:用户要往哪个域名发送上传请求。 policy:用户表单上传的策略(Policy),是经过base64编码过的字符串。 signature:对变量policy签名后的字符串。 expire:上传策略失效时间,在PolicyText里指定。在失效时间之前,都可以利用此Policy上传文件,所以没有必要每次上传都去服务端获取签名。 说明 为了减少服务端的压力,设计思路是:初始化上传时,每上传一个文件后,获取一次签名。然后再上传时,比较当前时间与签名时间,看签名时间是否失效。如果失效了,就重新获取一次签名,如果没有失效,就使用之前的签名。这里就用到了变量expire,核心代码如下:now = timestamp = Date.parse(new Date()) / 1000; [color=#000000]//可以判断当前expire是否超过了当前时间,如果超过了当前时间,就重新取一次签名,缓冲时间为3[/color] if (expire < now + 3) {    .....    phpUrl = './php/get.php'    xmlhttp.open( "GET", phpUrl, false );    xmlhttp.send( null );    ...... } return . 解析Policy的内容如下:{"expiration":"2015-11-05T20:23:23Z", "conditions":[["content-length-range",0,1048576000], ["starts-with","$key","user-dir/"]] 说明 Policy的详细信息请参见Policy基本元素。 上面Policy中增加了starts-with,用来指定此次上传的文件名必须以user-dir开头,用户可自行指定此字符串。增加starts-with的原因是:在很多场景下,一个应用对应一个Bucket,为了防止数字覆盖,每个用户上传到OSS的文件都可以有特定的前缀。这样就存在一个问题,用户获取到这个Policy后,在失效期内都能修改上传前缀,从而上传到别人的目录下。为了解决这个问题,可以设置应用服务器在上传时就指定用户上传的文件必须是某个前缀。这样如果用户获取到了Policy也没有办法上传到别人的前缀上,从而保证了数据的安全性。 总结 本示例中,web端向服务端请求签名,然后直接上传,不会对服务端产生压力,而且安全可靠。但是这个示例有个问题,就是用户上传了多少文件,上传了什么文件,服务端并不能马上知道,如果想实时了解用户上传了什么文件,可以采用服务端签名直传并设置上传回调。

2019-12-01 23:13:28 0 浏览量 回答数 0
阿里云大学 云服务器ECS com域名 网站域名whois查询 开发者平台 小程序定制 小程序开发 国内短信套餐包 开发者技术与产品 云数据库 图像识别 开发者问答 阿里云建站 阿里云备案 云市场 万网 阿里云帮助文档 免费套餐 开发者工具 企业信息查询 小程序开发制作 视频内容分析 企业网站制作 视频集锦 代理记账服务 2020阿里巴巴研发效能峰会 企业建站模板 云效成长地图 高端建站