All posts by 龙生

20个不可思议的 WebGL 示例和演示

WebGL 是一项在网页浏览器呈现3D画面的技术，有别于过去需要安装浏览器插件，通过 WebGL 的技术，只需要编写网页代码即可实现3D图像的展示。WebGL 可以为 Canvas 提供硬件3D加速渲染，这样 Web 开发人员就可以借助系统显卡来在浏览器里更流畅地展示3D场景和模型了。在这篇文章中20个不可思议的 WebGL 示例来增强你对于这个新技术的理解。 1. Aquarium Image Source:www.webglsamples.org Created by Greggman and Human Engines. The aquarium runs almost entirely based on a clock.That means the position of the camera and every fish will be the same across machines if their clocks are in sync. When in networked mode each machine keeps its clock in sync by periodically asking the server for the current time. 2. 3 Dreams of Black Image Source:www.ro.me A Semi-Intereactive film authored by Chris Milk. It was developed using technology developed by Google […]

龙生   26 Mar 2018
View Details

WebGL

WebGL（全写Web Graphics Library）是一种3D绘图协议，这种绘图技术标准允许把JavaScript和OpenGL ES 2.0结合在一起，通过增加OpenGL ES 2.0的一个JavaScript绑定，WebGL可以为HTML5 Canvas提供硬件3D加速渲染，这样Web开发人员就可以借助系统显卡来在浏览器里更流畅地展示3D场景和模型了，还能创建复杂的导航和数据视觉化。显然，WebGL技术标准免去了开发网页专用渲染插件的麻烦，可被用于创建具有复杂3D结构的网站页面，甚至可以用来设计3D网页游戏等等。

龙生   26 Mar 2018
View Details

ElasticSearch

ElasticSearch是一个基于Lucene的搜索服务器。它提供了一个分布式多用户能力的全文搜索引擎，基于RESTful web接口。Elasticsearch是用Java开发的，并作为Apache许可条款下的开放源码发布，是当前流行的企业级搜索引擎。设计用于云计算中，能够达到实时搜索，稳定，可靠，快速，安装使用方便。 我们建立一个网站或应用程序，并要添加搜索功能，但是想要完成搜索工作的创建是非常困难的。我们希望搜索解决方案要运行速度快，我们希望能有一个零配置和一个完全免费的搜索模式，我们希望能够简单地使用JSON通过HTTP来索引数据，我们希望我们的搜索服务器始终可用，我们希望能够从一台开始并扩展到数百台，我们要实时搜索，我们要简单的多租户，我们希望建立一个云的解决方案。因此我们利用Elasticsearch来解决所有这些问题及可能出现的更多其它问题。 下载地址：https://www.elastic.co/cn/downloads/elasticsearch

龙生   26 Mar 2018
View Details

浅谈我对DDD领域驱动设计的理解

从遇到问题开始 当人们要做一个软件系统时，一般总是因为遇到了什么问题，然后希望通过一个软件系统来解决。 比如，我是一家企业，然后我觉得我现在线下销售自己的产品还不够，我希望能够在线上也能销售自己的产品。所以，自然而然就想到要做一个普通电商系统，用于实现在线销售自己企业产品的目的。 再比如，我是一家互联网公司，公司有很多系统对外提供服务，面向很多客户端设备。但是最近由于各种原因，导致服务经常出故障。所以，我们希望通过各种措施提高服务的质量和稳定性。其中的一个措施就是希望能做一个灰度发布的平台，这个平台可以提供灰度发布的服务。然后，当某个业务系统做了一些修改并需要发布时，可以使用我们的灰度发布平台来非常方便的实现灰度发布的功能。比如在灰度发布平台上方便的定制允许哪些特定的客户端才会访问新服务，哪些客户端继续使用老服务。灰度发布平台可以提供各种灰度的策略。有了这样的灰度发布机制，那即便系统的新逻辑有什么问题，受影响的面也不会很大，在可控范围内。所以，如果公司里的所有对外提供服务的系统都接入了灰度平台，那这些系统的发布环节就可以更加有保障了。 总之，我们做任何一个软件系统，都是有原因的，否则就没必要做这个系统，而这个原因就是我们遇到的问题。所以，通过问题，我们就知道了我们需要一个什么样的系统，这个系统解决什么样的问题。最后，我们就很自然的得出了一个目标，即知道了自己要什么。比如我要做一个论坛、一个博客系统、一个电商平台、一个灰度发布系统、一个IDE、一个分布式消息队列、一个通信框架，等等。 DDD切入点1 – 理解概念 DDD的全称为Domain-driven Design，即领域驱动设计。下面我从领域、问题域、领域模型、设计、驱动这几个词语的含义和联系的角度去阐述DDD是如何融入到我们平时的软件开发初期阶段的。要理解什么是领域驱动设计，首先要理解什么是领域，什么是设计，还有驱动是什么意思，什么驱动什么。 什么是领域（Domain）？ 前面我们已经清楚的知道我们现在要做一个什么样的系统，这个系统需要解决什么问题。我认为任何一个系统都会属于某个特定的领域，比如论坛是一个领域，只要你想做一个论坛，那这个论坛的核心业务是确定的，比如都有用户发帖、回帖等核心基本功能。比如电商平台、普通电商系统，这种都属于网上电商领域，只要是这个领域的系统，那都有商品浏览、购物车、下单、减库存、付款交易等核心环节。所以，同一个领域的系统都具有相同的核心业务，因为他们要解决的问题的本质是类似的。 因此，我们可以推断出，一个领域本质上可以理解为就是一个问题域，只要是同一个领域，那问题域就相同。所以，只要我们确定了系统所属的领域，那这个系统的核心业务，即要解决的关键问题、问题的范围边界就基本确定了。通常我们说，要成为一个领域的专家，必须要在这个领域深入研究很多年才行。因为只有你研究了很多年，你才会遇到非常多的该领域的问题，同时你解决这个领域中的问题的经验也非常丰富。很多时候，领域专家比技术专家更加吃香，比如金融领域的专家。 什么是设计（Design）？ DDD中的设计主要指领域模型的设计。为什么是领域模型的设计而不是架构设计或其他的什么设计呢？因为DDD是一种基于模型驱动开发的软件开发思想，强调领域模型是整个系统的核心，领域模型也是整个系统的核心价值所在。每一个领域，都有一个对应的领域模型，领域模型能够很好的帮我们解决复杂的业务问题。 从领域和代码实现的角度来理解，领域模型绑定了领域和代码实现，确保了最终的代码实现就一定是解决了领域中的核心问题的。因为：1）领域驱动领域模型设计；2）领域模型驱动代码实现。我们只要保证领域模型的设计是正确的，就能确定领域模型可以解决领域中的核心问题；同理，我们只要保证代码实现是严格按照领域模型的意图来落地的，那就能保证最后出来的代码能够解决领域的核心问题的。这个思路，和传统的分析、设计、编码这几个阶段被割裂（并且每个阶段的产物也不同）的软件开发方法学形成鲜明的对比。 什么是驱动（Driven）？ 上面其实已经提到了，就是：1）领域驱动领域模型设计；2）领域模型驱动代码实现。这个就和我们传统的数据库驱动开发的思路形成对比了。DDD中，我们总是以领域为边界，分析领域中的核心问题（核心关注点），然后设计对应的领域模型，再通过领域模型驱动代码实现。而像数据库设计、持久化技术等这些都不是DDD的核心，而是外围的东西。 领域驱动设计（DDD）告诉我们的最大价值我觉得是：当我们要开发一个系统时，应该尽量先把领域模型想清楚，然后再开始动手编码，这样的系统后期才会很好维护。但是，很多项目（尤其是互联网项目，为了赶工）都是一开始模型没想清楚，一上来就开始建表写代码，代码写的非常冗余，完全是过程是的思考方式，最后导致系统非常难以维护。而且更糟糕的是，出来混总是要还的，前期的领域模型设计的不好，不够抽象，如果你的系统会长期需要维护和适应业务变化，那后面你一定会遇到各种问题维护上的困难，比如数据结构设计不合理，代码到处冗余，改BUG到处引入新的BUG，新人对这种代码上手困难，等。而那时如果你再想重构模型，那要付出的代价会比一开始重新开发还要大，因为你还要考虑兼容历史的数据，数据迁移，如何平滑发布等各种头疼的问题。所以，就导致我们最后天天加班。 虽然，我们都知道这个道理，但是我也明白，人的习惯很难改变的，大部分人都很难从面向过程式的想到哪里写到哪里的思想转变为基于系统化的模型驱动的思维。我想，这或许是DDD很难在中国或国外流行起来的原因吧。但是，我想这不应该成为我们放弃学习DDD的原因，对吧！ 概念总结： 领域就是问题域，有边界，领域中有很多问题； 任何一个系统要解决的那个大问题都对应一个领域； 通过建立领域模型来解决领域中的核心问题，模型驱动的思想； 领域建模的目标针对我们在领域中所关心的问题，即只针对核心关注点，而不是整个领域中的所有问题； 领域模型在设计时应考虑一定的抽象性、通用性，以及复用价值； 通过领域模型驱动代码的实现，确保代码让领域模型落地，代码最终能解决问题； 领域模型是系统的核心，是领域内的业务的直接沉淀，具有非常大的业务价值； 技术架构设计或数据存储等是在领域模型的外围，帮助领域模型进行落地； DDD切入点2 – 理解领域、拆分领域、细化领域 理解领域知识是基础 上面我们通过第一步，虽然我们明确了要做一个什么样的系统，该系统主要解决什么问题，但是就这样我们还无法开始进行实际的需求分析和模型设计，我们还必须将我们的问题进行拆分，需求进行细化。有些时候，需求方，即提出问题的人，很可能自己不清楚具体想要什么。他只知道一个概念，一个大的目标。比如他只知道要做一个股票交易系统，一个灰度发布系统，一个电商平台，一个开发工具，等。但是他不清楚这些系统应该具体做成什么样子。这个时候，我认为领域专家就非常重要了，DDD也非常强调领域专家的重要性。因为领域专家对这个领域非常了解，对领域内的各种业务场景和各种业务规则也非常清楚，总之，对这个领域内的一切业务相关的知识都非常了解。所以，他们自然就有能力表达出系统该做成什么样子。所以，要知道一个系统到底该做成什么样子，到底哪些是核心业务关注点，只能靠沉淀领域内的各种知识，别无他法。因此，假设你现在打算做一个电商平台，但是你对这个领域没什么了解，那你一定得先去了解下该领域内主流的电商平台，比如淘宝、天猫、京东、亚马逊等。这个了解的过程就是你沉淀领域知识的过程。如果你不了解，就算你领域建模的能力再强，各种技术架构能力再强也是使不上力。领域专家不是某个固定的角色，而是某一类人，这类人对这个领域非常了解。比如，一个开发人员也可以是一个领域专家。假设你在一个公司开发和维护一个系统已经好几年了，但是这个系统的产品经理（PD）可能已经换过好几任了，这种情况下，我相信这几任产品经理都没有比你更熟悉这个领域。 拆分领域 上面我们明白了，领域建模的基础是要先理解领域，让自己成为领域专家。如果做到了这点，我们就打好了坚实的基础了。但是，有时一个领域往往太复杂，涉及到的领域概念、业务规则、交互流程太多，导致我们没办法直接针对这个大的领域进行领域建模。所以，我们需要将领域进行拆分，本质上就是把大问题拆分为小问题，然后各个击破的思路。然后既然把一个大的领域划分为了多个小的领域（子域），那最关键的就是要理清每个子域的边界；然后要搞清楚哪些子域是核心子域，哪些是非核心子域，哪些是公共支撑子域；然后，还要思考子域之间的联系是什么。那么，我们该如何划分子域呢？我的个人看法是从业务相关性的角度去思考，也就是我们平时说的按业务功能为出发点进行划分。还是拿经典的电商系统来分析，通常一个电商系统都会包含好几个大块，比如： 会员中心：负责用户账号登录、用户信息的管理； 商品中心：负责商品的展示、导航、维护； 订单中心：负责订单的生成和生命周期管理； 交易中心：负责交易相关的业务； 库存中心：负责维护商品的库存； 促销中心：负责各种促销活动的支持； 上面这些中心看起来很自然，因为大家对电子商务的这个领域都已经非常熟悉了，所以都没什么疑问，好像很自然的样子。所以，领域划分是不是就是没什么挑战了呢？显然不是。之所以我们觉得子域划分很简单，是因为我们对整个大领域非常了解了。如果我们遇到一个冷门的领域，就没办法这么容易的去划分子域了。这就需要我们先去努力理解领域内的知识。所以，我个人从来不相信什么子域划分的技巧什么的东西，因为我觉得这个工作没有任何诀窍可以使用。当我们不了解一个东西的时候，如何去拆解它？当我们对整个领域有一定的熟悉了，了解了领域内的相关业务的本质和关系，我们就自然而然的能划分出合理的子域了。不过并不是所有的系统都需要划分子域的，有些系统只是解决一个小问题，这个问题不复杂，可能只有一两个核心概念。所以，这种系统完全不需要再划分子域。但不是绝对的，当一个领域，我们的关注点越来越多，每个关注点我们关注的信息越来越多的时候，我们会不由自主的去进一步的划分子域。比如，也许我们一开始将商品和商品的库存都放在商品中心里，但是后来由于库存的维护越来越复杂，导致揉在一起对我们的系统维护带来一定的困难时，我们就会考虑将两者进行拆分，这个就是所谓的业务垂直分割。 细化子域 通过上面的两步，我们了解了领域里的知识，也对领域进行了子域划分。但这样还不够，凭这些我们还无法进行后续的领域模型设计。我们还必须再进一步细化每个子域，进一步明确每个子域的核心关注点，即需求细化。我觉得我们需要细化的方面有以下几点： 梳理领域概念：梳理出领域内我们关注的概念、概念的关系，并统一交流词汇，形成统一语言； 梳理业务规则：梳理出领域内我们关注的各种业务规则，DDD中叫不变性（invariants），比如唯一性规则，余额不能小于零等； 梳理业务场景：梳理出领域内的核心业务场景，比如电商平台中的加入购物车、提交订单、发起付款等核心业务场景； 梳理业务流程：梳理出领域内的关键业务流程，比如订单处理流程，退款流程等； 从上面这4个方面，我们从领域概念、业务规则、交互场景、业务流程等维度梳理了我们到底要什么，整理了整个系统应该具备的功能。这个工作我觉得是一个非常具有创造性和有难度的工作。我们一方面会主观的定义我们想要什么；另一方面，我们还会思考我们要的东西的合理性。我认为这个就是产品经理的工作，产品经理必须要负起职责，把他的产品充分设计好，从各个方面去考虑，如何设计一个产品，才能更好的解决用户的核心诉求，即领域内的核心问题。如果对领域不够了解，如果想不清楚用户到底要什么，如果思考问题不够全面，谈何设计出一个合理的产品呢？ 关于领域概念的梳理，我觉得可以采用四色原型分析法，这个分析法通过系统的方法，将概念划分为不同的种类，为不同种类的概念标注不同的颜色。然后将这些概念有机的组合起来，从而让我们可以清晰的分析出概念和概念之间的关系。有兴趣的同学可以在网上搜索下四色原型。 注意：上面我说的这四点，重点是梳理出我们要什么功能，而不是思考如何实现这些功能，如何实现是软件设计人员的职责。 DDD切入点3 – 领域模型设计 这部分内容，我想学习DDD的人都很熟悉了。DDD原著中提出了很多实用的建模工具：聚合、实体、值对象、工厂、仓储、领域服务、领域事件。我们可以使用这些工具，来设计每一个子域的领域模型。最终通过领域模型图将设计沉淀下来。要使用这些工具，首先就要理解每个工具的含义和使用场景。不要以为很简单哦，比如聚合的划分就是一个非常具有艺术的活。同一个系统，不同的人设计出来的聚合是完全不同的。而且很有可能高手之间的最后设计出来的差别反而更大，实际上我认为是世界观的相互碰撞，呵呵。所以，要领域建模，我觉得每个人都应该去学学哲学知识，这有助于我们更好的认识世界，更好的理解事物的本质。 关于这些建模工具的概念和如何运用我就不多展开了，我博客里也有很多这方面的介绍。下面我再讲一下我认为比较重要的东西，比如到底该如何领域建模？步骤应该是怎么样的？ 领域建模的方法 通过上面我介绍的细化子域的内容，现在再来谈该如何领域建模，我觉得就方便很多了。我的主要方法是： 划分好边界上下文，通常每个子域（sub domain）对应一个边界上下文（bounded context），同一个边界上下文中的概念是明确的，没有任何歧义； 在每个边界上下文中设计领域模型，具体的领域模型设计方法有很多种，如以场景为出发点的四色原型分析法，或者我早期写的这篇文章；这个步骤最核心的就是找出聚合根，并找出每个聚合根包含的信息；关于如何设计聚合，可以看一下我写的这篇文章； 画出领域模型图，圈出每个模型中的聚合边界； 设计领域模型时，要考虑该领域模型是否满足业务规则，同时还要综合考虑技术实现等问题，比如并发问题；领域模型不是概念模型，概念模型不关注技术实现，领域模型关心；所以领域模型才能直接指导编码实现； 思考领域模型是如何在业务场景中发挥作用的，以及是如何参与到业务流程的每个环节的； 场景走查，确认领域模型是否能满足领域中的业务场景和业务流程； 模型持续重构、完善、精炼； 领域模型的核心作用： 抽象了领域内的核心概念，并建立概念之间的关系； 领域模型承担了领域内的状态的维护； 领域模型维护了领域内的数据之间的业务规则，数据一致性； 下图是我最近做个一个普通电商系统的商品中心的领域模型图，给大家参考： 领域模型设计只是软件设计中的一小部分 需要特别注意的是，领域模型设计只是整个软件设计中的很小一部分。除了领域模型设计之外，要落地一个系统，我们还有非常多的其他设计要做，比如： 容量规划 架构设计 数据库设计 缓存设计 框架选型 发布方案 数据迁移、同步方案 分库分表方案 回滚方案 高并发解决方案 一致性选型 性能压测方案 监控报警方案 […]

龙生   26 Mar 2018
View Details

RabbitMQ系列(一)：Windows下RabbitMQ安装及入门

1.Windows下安装RabbitMQ需要以下几个步骤 (1)：下载erlang，原因在于RabbitMQ服务端代码是使用并发式语言erlang编写的，下载地址：http://www.erlang.org/downloads，双击.exe文件进行安装就好，安装完成之后创建一个名为ERLANG_HOME的环境变量，其值指向erlang的安装目录，同时将%ERLANG_HOME%\bin加入到Path中，最后打开命令行，输入erl，如果出现erlang的版本信息就表示erlang语言环境安装成功； (2)：下载RabbitMQ，下载地址：http://www.rabbitmq.com/，同样双击.exe进行安装就好(这里需要注意一点，默认的安装目录是C:/Program Files/….，这个目录中是存在空格符的，我们需要改变安装目录，貌似RabbitMQ安装目录中是不允许有空格的，我之前踩过这个大坑)； (3)：安装RabbitMQ-Plugins，这个相当于是一个管理界面，方便我们在浏览器界面查看RabbitMQ各个消息队列以及exchange的工作情况，安装方法是：打开命令行cd进入rabbitmq的sbin目录(我的目录是：E:\software\rabbitmq\rabbitmq_server-3.6.5\sbin)，输入：rabbitmq-plugins enable rabbitmq_management命令，稍等会会发现出现plugins安装成功的提示，默认是安装6个插件，如果你在安装插件的过程中出现了下面的错误： 解决方法是：首先在命令行输入：rabbitmq-service stop，接着输入rabbitmq-service remove，再接着输入rabbitmq-service install，接着输入rabbitmq-service start，最后重新输入rabbitmq-plugins enable rabbitmq_management试试，我是这样解决的； (4)：插件安装完之后，在浏览器输入http://localhost:15672进行验证，你会看到下面界面，输入用户名：guest，密码：guest你就可以进入管理界面，当然用户名密码你都可以变的； 2.安装完RabbitMQ之后，我们先来简单了解下RabbitMQ中涉及到的几个概念 producer：消息生产者 consumer：消息消费者 virtual host：虚拟主机，在RabbitMQ中，用户只能在虚拟主机的层面上进行一些权限设置，比如我可以访问哪些队列，我可以处理哪些请求等等； broker：消息转发者，也就是我们RabbitMQ服务端充当的功能了，那么消息是按照什么规则进行转发的呢？需要用到下面几个概念； exchange：交换机，他是和producer直接进行打交道的，有点类似于路由器的功能，主要就是进行转发操作的呗，那么producer到底用哪个exchange进行路由呢？这个取决于routing key(路由键)，每个消息都有这个键，我们也可以自己设定，其实就是一字符串； queue：消息队列，用于存放消息，他接收exchange路由过来的消息，我们可以对队列内容进行持久化操作，那么queue到底接收那个exchange路由的消息呢？这个时候就要用到binding key(绑定键)了，绑定键会将队列和exchange进行绑定，至于绑定方式，RabbitMQ提供了多种方式，大家可以看看鸿洋大神的RabbitMQ博客系列(点击查看)； 以上就是RabbitMQ涉及到的一些概念了，用一张图表示这些概念之间的关系就是： 3.RabbitMQ简单使用 producer(生产者)端步骤： (1)：创建ConnectionFactory，并且设置一些参数，比如hostname,portNumber等等 (2)：利用ConnectionFactory创建一个Connection连接 (3)：利用Connection创建一个Channel通道 (4)：创建queue并且和Channel进行绑定 (5)：创建消息，并且发送到队列中 注意，在我们当前的例子中，并没有用到exchange交换机，RabbitMQ默认情况下是会创建一个空字符串名字的exchange的，如果我们没有创建自己的exchange的话，默认就是使用的这个exchange； producer端代码：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
public class Sender {
private final static String QUEUE_NAME = "MyQueue";
public static void main(String[] args) {
send();
}
public static void send()
{
ConnectionFactory factory = null;
Connection connection = null;
Channel channel = null;
try {
factory = new ConnectionFactory();
factory.setHost("localhost");
connection = factory.newConnection();
channel = connection.createChannel();
channel.queueDeclare(QUEUE_NAME, false, false, false, null);
String message = "my first message .....";
channel.basicPublish("", QUEUE_NAME, null, message.getBytes("UTF-8"));
System.out.println("已经发送消息....."+message);
} catch (IOException e) {
e.printStackTrace();
} catch (TimeoutException e) {
e.printStackTrace();
}finally{
try {
//关闭资源
channel.close();
connection.close();
} catch (IOException e) {
e.printStackTrace();
} catch (TimeoutException e) {
e.printStackTrace();
}
}
}
}

consumer(消费者)端步骤： (1)：创建ConnectionFactory，并且设置一些参数，比如hostname,portNumber等等 (2)：利用ConnectionFactory创建一个Connection连接 (3)：利用Connection创建一个Channel通道 (4)：将queue和Channel进行绑定，注意这里的queue名字要和前面producer创建的queue一致 (5)：创建消费者Consumer来接收消息，同时将消费者和queue进行绑定 consumer端代码：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
public class Receiver {
private final static String QUEUE_NAME = "MyQueue";
public static void main(String[] args) {
receive();
}
public static void receive()
{
ConnectionFactory factory = null;
Connection connection = null;
Channel channel = null;
try {
factory = new ConnectionFactory();
factory.setHost("localhost");
connection = factory.newConnection();
channel = connection.createChannel();
channel.queueDeclare(QUEUE_NAME, false, false, false, null);
Consumer consumer = new DefaultConsumer(channel){
@Override
public void handleDelivery(String consumerTag, Envelope envelope, BasicProperties properties,
byte[] body) throws IOException {
System.out.println("11111111111");
String message = new String(body, "UTF-8");
System.out.println("收到消息....."+message);
}};
channel.basicConsume(QUEUE_NAME, true,consumer);
} catch (IOException e) {
e.printStackTrace();
} catch (TimeoutException e) {
e.printStackTrace();
}finally{
try {
//关闭资源
channel.close();
connection.close();
} catch (IOException e) {
e.printStackTrace();
} catch (TimeoutException e) {
e.printStackTrace();
}
}
}
}

好了，这篇先到这了，下一篇我会简单介绍点更深入的东西，后续也会对RabbitMQ原生API进行封装，便于我们自己开发； from:https://blog.csdn.net/hzw19920329/article/details/53156015

龙生   26 Mar 2018
View Details

ABP入门教程

ABP是“ASP.NET Boilerplate Project (ASP.NET样板项目)”的简称。 ASP.NET Boilerplate是一个用最佳实践和流行技术开发现代WEB应用程序的新起点，它旨在成为一个通用的WEB应用程序框架和项目模板。 ABP的官方网站 ： http://www.aspnetboilerplate.com ABP在Github上的开源项目：https://github.com/aspnetboilerplate ABP 的由来 “DRY——避免重复代码”是一个优秀的开发者在开发软件时所具备的最重要的思想之一。我们在开发企业WEB应用程序时都有一些类似的需求，例如：都需要登录页面、用户/角色管理、权限验证、数据有效性验证、多语言/本地化等等。一个高品质的大型软件都会运用一些最佳实践，例如分层体系结构、领域驱动设计、依赖注入等。我们也可能会采用ORM、数据库迁移（Database Migrations）、日志记录（Logging）等工具。 从零开始创建一个企业应用程序是一件繁琐的事，因为需要重复做很多常见的基础工作。许多公司都在开发自己的应用程序框架来重用于不同的项目，然后在框架的基础上开发一些新的功能。但并不是每个公司都有这样的实力。假如我们可以分享的更多，也许可以避免每个公司或每个项目的重复编写类似的代码。作者之所以把项目命名为“ASP.NET Boilerplate”，就是希望它能成为开发一般企业WEB应用的新起点，直接把ABP作为项目模板。 ABP是什么？ ABP是为新的现代Web应用程序使用最佳实践和使用最流行工具的一个起点。可作为一般用途的应用程序的基础框架或项目模板。它的功能包括： 服务器端： 基于最新的.NET技术 （目前是ASP.NET MVC 5、Web API 2、C# 5.0，在ASP.NET 5正式发布后会升级） 实现领域驱动设计（实体、仓储、领域服务、领域事件、应用服务、数据传输对象，工作单元等等） 实现分层体系结构（领域层，应用层，展现层和基础设施层） 提供了一个基础架构来开发可重用可配置的模块 集成一些最流行的开源框架/库，也许有些是你正在使用的。 提供了一个基础架构让我们很方便地使用依赖注入（使用Castle Windsor作为依赖注入的容器） 提供Repository仓储模式支持不同的ORM（已实现Entity Framework 、NHibernate、MangoDb和内存数据库） 支持并实现数据库迁移（EF 的 Code first） 模块化开发（每个模块有独立的EF DbContext，可单独指定数据库） 包括一个简单的和灵活的多语言/本地化系统 包括一个 EventBus来实现服务器端全局的领域事件 统一的异常处理（应用层几乎不需要处理自己写异常处理代码） 数据有效性验证（Asp.NET MVC只能做到Action方法的参数验证，ABP实现了Application层方法的参数有效性验证） 通过Application Services自动创建Web Api层（不需要写ApiController层了） 提供基类和帮助类让我们方便地实现一些常见的任务 使用“约定优于配置原则” 客户端： Bootstrap、Less、AngularJs、jQuery、Modernizr和其他JS库: jQuery.validate、jQuery.form、jQuery.blockUI、json2等 为单页面应用程序（AngularJs、Durandaljs）和多页面应用程序（Bootstrap+Jquery）提供了项目模板。 自动创建Javascript 的代理层来更方便使用Web Api 封装一些Javascript 函数，更方便地使用ajax、消息框、通知组件、忙状态的遮罩层等等 除ABP框架项目以外，还开发了名叫“Zero”的模块，实现了以下功能： 身份验证与授权管理（通过ASP.NET Identity实现的） 用户&角色管理 系统设置存取管理（系统级、租户级、用户级，作用范围自动管理） 审计日志（自动记录每一次接口的调用者和参数） ABP不是什么？ ABP 提供了一个应用程序开发模型用于最佳实践。它拥有基础类、接口和工具使我们容易建立起可维护的大规模的应用程序。 然而： 它不是RAD工具之一，RAD工具的目的是无需编码创建应用程序。相反，ABP提供了一种编码的最佳实践。 它不是一个代码生成工具。在运行时虽然它有一些特性构建动态代码，但它不能生成代码。 它不是一个一体化的框架。相反，它使用流行的工具/库来完成特定的任务（例如用EF做ORM，用Log4Net做日志记录，使得Castle Windsor作为赖注入容器， AngularJs 用于SPA 框架）。 就我使用了ABP几个月的经验来看，虽然ABP不是RAD，但是用它开发项目绝对比传统三层架构要快很多。 虽然ABP不是代码生成工具，但因为有了它，使我们项目的代码更简洁规范，这有利于使用代码生成工具。 我自己使用VS2013的Scaffolder+T4开发的代码生成器，可根据领域对象的UML类图自动生成全部前后端代码和数据库，简单的CURD模块几乎不需要编写代码，有复杂业务逻辑的模块主要补充领域层代码即可。这样就能把时间多花在领域模型的设计上，减少写代码的时间。 下面通过原作者的“简单任务系统”例子，演示如何运用ABP开发项目 从模板创建空的web应用程序 ABP提供了一个启动模板用于新建的项目（尽管你能手动地创建项目并且从nuget获得ABP包，模板的方式更容易）。 转到www.aspnetboilerplate.com/Templates从模板创建你的应用程序。 你可以选择SPA（AngularJs或DurandalJs）或者选择MPA（经典的多页面应用程序）项目。可以选择Entity Framework或NHibernate作为ORM框架。 这里我们选择AngularJs和Entity Framework，填入项目名称“SimpleTaskSystem”，点击“CREATE […]

龙生   25 Mar 2018
View Details

聊聊ASP.NET Core默认提供的这个跨平台的服务器——KestrelServer

跨平台是ASP.NET Core一个显著的特性，而KestrelServer是目前微软推出了唯一一个能够真正跨平台的Server。KestrelServer利用一个名为KestrelEngine的网络引擎实现对请求的监听、接收和响应。KetrelServer之所以具有跨平台的特质，源于KestrelEngine是在一个名为libuv的跨平台网络库上开发的。 目录 一、libuv 二、KestrelServer 三、KestrelServerOptions 四、ApplicationLifetime 五、设置监听地址 一、libuv 说起libuv，就不得不谈谈libev，后者是Unix系统上一个事件循环和事件模型的网络库。libev因其具有的高性能成为了继lievent和Event perl module之后一套最受欢迎的网络库。由于Libev不支持Windows，有人在libev之上创建了一个抽象层以屏蔽平台之间的差异，这个抽象层就是libuv。libuv在Windows平台上是采用IOCP的形式实现的，右图揭示了libuv针对Unix和Windows的跨平台实现原理。到目前为止，libuv支持的平台已经不限于Unix和Windows了，包括Linux（2.6）、MacOS和Solaris （121以及之后的版本）在内的平台在libuv支持范围之内。 二、KestrelServer 如下所示的代码片段体现了KestrelServer这个类型的定义。除了实现接口IServer定义的Features属性之外，KestrelServer还具有一个类型为KestrelServerOptions的只读属性Options。这个属性表示对KestrelServer所作的相关设置，我们在调用构造函数时通过输入参数options所代表的IOptions<KestrelServerOptions>对象对这个属性进行初始化。构造函数还具有另两个额外的参数，它们的类型分别是IApplicationLifetime和ILoggerFactory，后者用于创建记录日志的Logger，前者与应用的生命周期管理有关。

1
2
3
4
5
6
7
8
9
   1: public class KestrelServer : IServer
   2: {
   3:     public IFeatureCollection       Features { get; }
   4:     public KestrelServerOptions     Options { get; }
   5:
   6:     public KestrelServer(IOptions<KestrelServerOptions> options,IApplicationLifetime applicationLifetime, ILoggerFactory loggerFactory);
   7:     public void Dispose();
   8:     public void Start<TContext>(IHttpApplication<TContext> application);
   9: }

我们一般通过调用WebHostBuilder的扩展方法UseKestrel方法来完成对KestrelServer的注册。如下面的代码片段所示，UseKestrel方法具有两个重载，其中一个具有同一个类型为Action<KestrelServerOptions>的参数，我们可以利用这个参数直接完成对KestrelServerOptions的设置。

1
2
3
4
5
   1: public static class WebHostBuilderKestrelExtensions
   2: {
   3:     public static IWebHostBuilder UseKestrel(this IWebHostBuilder hostBuilder);
   4:     public static IWebHostBuilder UseKestrel(this IWebHostBuilder hostBuilder, Action<KestrelServerOptions> options);
   5: }

三、KestrelServerOptions 由于Server负责请求的监听、接收和响应，所以Server是影响整个Web应用响应能力和吞吐量最大的因素之一，为了更加有效地使用Server，我们往往针对具体的网络负载状况对其作针对性的设置。对于KestrelServer来说，在构造函数中作为参数指定的KestrelServerOptions对象代表针对它所做的设置。我们针对KestrelServer所做的设置主要体现在KestrelServerOptions类型的如下5个属性上。

1
2
3
4
5
6
7
8
9
   1: public class KestrelServerOptions
   2: {
   3:     //省略其他成员
   4:     public int          MaxPooledHeaders { get; set; }
   5:     public int          MaxPooledStreams { get; set; }
   6:     public bool         NoDelay { get; set; }
   7:     public TimeSpan     ShutdownTimeout { get; set; }
   8:     public int          ThreadCount { get; set; }
   9: }

  KestrelServerOptions注册的KetrelServer在管道中会以依赖注入的方式被创建，并采用构造器注入的方式提供其构造函数的参数options，由于这个参数类型为IOptions<KestrelServerOptions>，所以我们利用Options模型以配置的方式来指定KestrelServerOptions对象承载的设置。比如我们可以将KestrelServer的相关配置定义在如下一个JSON文件中。

1
2
3
4
5
   1: {
   2:     "noDelay"         : false,
   3:     "shutdownTimeout" : "00:00:10",
   4:     "threadCount"     : 10
   5: }

为了让应用加载这么一个配置文件（文件名假设为“KestrelServerOptions.json”），我们只需要在启动类型（Startup）类的ConfigureServces方法中按照如下的方式利用ConfigurationBuilder加载这个配置文件并生成相应的Configuration对象，最后按照Options模型的编程方式完成KestrelServerOptions类型和该对象的映射即可。

1
2
3
4
5
6
7
8
9
10
11
   1: public class Startup
   2: {
   3:     //其他成员
   4:     public void ConfigureServices(IServiceCollection services)
   5:     {
   6:         IConfiguration configuration = new ConfigurationBuilder()
   7:             .AddJsonFile("KestrelServerOptions.json")
   8:             .Build();
   9:         services.Configure<KestrelServerOptions>(configuration);
  10:     }
  11: }

四、ApplicationLifetime 我们将所有实现了IApplicationLifetime接口的所有类型及其对应对象统称为ApplicationLifetime。从命名的角度来看，ApplicationLifetime貌似是对当前应用生命周期的描述，而实际上它存在的目的仅仅是在应用启动和关闭（只要是关闭）时对相关组件发送通知而已。如下面的代码片段所示，IApplicationLifetime接口具有三个CancellationToken类型的属性（ApplicationStarted、ApplicationStopping和ApplicationStopped），我们可以利用它们是否已经被取消（Cancel）确定当前应用的状态（已经开启、正在关闭和已经关闭）。如果试图关闭应用，StopApplication方法应该被调用以发出应用正在被关闭的通知。对于KestrelServer来说，如果请求处理线程中发生未被处理异常，它会调用这个方法。

1
2
3
4
5
6
7
8
   1: public interface IApplicationLifetime
   2: {
   3:     CancellationToken ApplicationStarted { get; }
   4:     CancellationToken ApplicationStopping { get; }
   5:     CancellationToken ApplicationStopped { get; }
   6:
   7:     void StopApplication();
   8: }

ASP.NET Core默认使用的ApplicationLifetime是具有如下定义的一个同名类型。可以看出它实现的三个属性返回的CancellationToken对象是通过三个对应的CancellationTokenSource生成。除了实现IApplicationLifetime接口的StopApplication方法用于发送“正在关闭”通知之外，这个类型还定义了额外两个方法（NotifyStarted和NotifyStopped）用于发送“已经开启/关闭”的通知。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
   1: public class ApplicationLifetime : IApplicationLifetime
   2: {
   3:     private readonly CancellationTokenSource _startedSource = new CancellationTokenSource();
   4:     private readonly CancellationTokenSource _stoppedSource = new CancellationTokenSource();
   5:     private readonly CancellationTokenSource _stoppingSource = new CancellationTokenSource();
   6:
   7:     public CancellationToken ApplicationStarted
   8:     {
   9:         get { return this._startedSource.Token; }
  10:     }
  11:     public CancellationToken ApplicationStopped
  12:     {
  13:         get { return this._stoppedSource.Token; }
  14:     }
  15:     public CancellationToken ApplicationStopping
  16:     {
  17:         get { return this._stoppingSource.Token; }
  18: }
  19:
  20:     public void NotifyStarted()
  21:     {
  22:         this._startedSource.Cancel(false);
  23:     }
  24:     public void NotifyStopped()
  25:     {
  26:         this._stoppedSource.Cancel(false);
  27:     }
  28:     public void StopApplication()
  29:     {
  30:         this._stoppingSource.Cancel(false);
  31:     }
  32: }

一个ASP.NET Core应用利用管道处理请求，所以管道的生命周期等同于应用自身的生命周期。当我们调用Run方法开启WebHost时，请求处理管道被构建出来。如果管道在处理请求时发生未被处理的异常，管道的Sever会调用ApplicationLifeTime对象的StopApplication方法向WebHost发送关闭应用的通知以便后者执行一些回收释放工作。 五、设置监听地址 在演示的实例中，我们实际上并不曾为注册的KestrelServer指定一个监听地址，从运行的效果我们不难看出，WebHost在这种情况下会指定“http://localhost:5000”为默认的监听地址，Server的监听地址自然可以显式指定。在介绍如何通过编程的方式为Server指定监听地址之前，我们有先来认识一个名为ServerAddressesFeature的特性。 我们知道表示Server的接口IServer中定义了一个类型为IFeatureCollection 的只读属性Features，它表示用于描述当前Server的特性集合，ServerAddressesFeature作为一个重要的特性，就包含在这个集合之中。我们所说的ServerAddressesFeature对象是对所有实现了IServerAddressesFeature接口的所有类型及其对应对象的统称，该接口具有一个唯一的只读属性返回Server的监听地址列表。ASP.NET Core默认使用的ServerAddressesFeature是具有如下定义的同名类型。

1
2
3
4
5
6
7
8
9
   1: public interface IServerAddressesFeature
   2: {
   3:     ICollection<string> Addresses { get; }
   4: }
   5:
   6: public class ServerAddressesFeature : IServerAddressesFeature
   7: {
   8:     public ICollection<string> Addresses { get; }
   9: }

对于WebHost在通过依赖注入的方式创建的Server，由它的Features属性表示的特性集合中会默认包含这么一个ServerAddressesFeature对象。如果没有一个合法的监听地址被添加到这个 ServerAddressesFeature对象的地址列表中，WebHost会将显式指定的地址（一个或者多个）添加到该列表中。我们显式指定的监听地址实际上是作为WebHost的配置保存在一个Configuration对象上，配置项对应的Key为“server.urls”，WebHostDefaults的静态只读属性ServerUrlsKey返回的就是这么一个Key。

1
2
3
4
5
6
   1: new WebHostBuilder()
   2:     .UseSetting(WebHostDefaults.ServerUrlsKey, "http://localhost:3721/")
   3:     .UseMyKestrel()
   4:     .UseStartup<Startup>()
   5:     .Build()
   6:      .Run();

WebHost的配置最初来源于创建它的WebHostBuilder，后者提供了一个UseSettings方法来设置某个配置项的值，所以我们可以采用如下的方式来指定监听地址（“http://localhost:3721/”）。不过，针对监听地址的显式设置，最直接的编程方式还是调用WebHostBuilder的扩展方法UseUrls，如下面的代码片段所示，该方法的实现逻辑与上面完全一致。

1
2
3
4
5
   1: public static class WebHostBuilderExtensions
   2: {
   3:     public static IWebHostBuilder UseUrls(this IWebHostBuilder hostBuilder, params string[] urls)
   4:     =>hostBuilder.UseSetting(WebHostDefaults.ServerUrlsKey, string.Join(ServerUrlsSeparator, urls)) ;
   5: }

  from:https://www.cnblogs.com/artech/p/KestrelServer.html

龙生   25 Mar 2018
View Details

ASP.NET Core的Kestrel服务器

原文地址—-Kestrel server for ASP.NET Core By Tom Dykstra, Chris Ross, and Stephen Halter Kestrel是一个基于libuv的跨平台ASP.NET Core web服务器，libuv是一个跨平台的异步I/O库。ASP.NET Core模板项目使用Kestrel作为默认的web服务器。 Kestrel支持以下功能： HTTPS 用于启用不透明升级的WebSockets 位于Nginx之后的高性能Unix sockets Kestrel 被.NET Core支持的所有平台和版本所支持 查看或下载示例代码 何时使用Kestrel和反向代理服务器 如果你的应用只接收来自内部网络的请求，你可以只使用Kestrel本身。 如果你将你的应用部署在公共网络上，我们建议你使用IIS，Nginx或者Apache作为反向代理服务器。一个反向代理服务器接收来自网络的HTTP请求并且在经过一些初步处理后将请求传递到Kestrel服务器。 出于安全性的理由，反向代理常常被edge deployments所采用。因为Kestrel相对较新，对抵御安全攻击至今还没有一个完整的功能补充。安全性处理包括但不限于适当的超时，大小的限制，以及并发连接限制等问题。 另一个需要反向代理的场景是，你有多个需要在单独的服务器上运行并分享同一端口的应用。因为Kestrel不支持在多进程间分享同一端口，所以应用并不能直接和Kestrel合作。当你在某个端口上配置Kestrel运行侦听时，不算主机头如何标识，Kestrel会为该端口处理所有的流量。反向代理可以为多个应用共享唯一端口并将流量发送给Kestrel。 即使不需要反向代理服务器，使用它也可以简化负载均衡和SSL设置 — 只要你的反向代理服务器需要SSL证书，并且该服务器可以和你的应用在内部网中通过普通HTTP进行通信。 如何在ASP.NET Core应用中使用Kestrel 安装 Microsoft.AspNetCore.Server.Kestrel Nuget包。 在应用的Main方法中调用WebHostBuilder的UseKestrel 扩展方法，指定你需要的Kestrel选项，如以下示例所示：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
public static int Main(string[] args)
{
    Console.WriteLine("Running demo with Kestrel.");
 
    var config = new ConfigurationBuilder()
        .AddCommandLine(args)
        .Build();
 
    var builder = new WebHostBuilder()
        .UseContentRoot(Directory.GetCurrentDirectory())
        .UseConfiguration(config)
        .UseStartup<Startup>()
        .UseKestrel(options =>
        {
            if (config["threadCount"] != null)
            {
                options.ThreadCount = int.Parse(config["threadCount"]);
            }
        })
        .UseUrls("http://localhost:5000");
 
    var host = builder.Build();
    host.Run();
 
    return 0;
}

URL 前缀 默认情况下，ASP.NET Core项目绑定了http://localhost:5000。通过使用UseUrls扩展方法——编辑urls命令行参数，或者是通过ASP.NET Core配置系统，你可以为Ketrel配置URL前缀和端口号以用来侦听请求。关于这些方法更多的信息，请参考Hosting。有关于当你使用IIS作为反向代理时，URL绑定是如何工作的信息，请参考ASP.NET Core 模块。 Kestrel URL前缀可以是以下格式中的任一种。 IPv4 地址和端口号

1
2
http://65.55.39.10:80/
https://65.55.39.10:443/

IPv6 地址和端口号

1
2
http://[0:0:0:0:0:ffff:4137:270a]:80/
https://[0:0:0:0:0:ffff:4137:270a]:443/

IPv6中的 [::] 等价于 IPv4 0.0.0.0。 主机名和端口号

1
2
3
4
http://contoso.com:80/
http://*:80/
https://contoso.com:443/
https://*:443/

  主机名称，*，以及+，都不是特殊的。任何没有公认的IP 或是“localhost”的地址将绑定到所有的IPv4和IPv6的IP上。如果你需要为不同的ASP.NET Core应用在同一端口上绑定不同的主机名，请使用WebListener或者诸如IIS，Nginx或Apache这样的反向代理服务器。 *　"Localhost" 名称和端口号或回送IP地址和端口号

1
2
3
http://localhost:5000/
http://127.0.0.1:5000/
http://[::1]:5000/

  当localhost被指定时，Kestrel会尝试去绑定到IPv4和IPv6的环回接口。如果被请求的端口号正在任一环回接口上被其他服务所使用，Kestrel将会启动失败。如果任一环回接口出于各种原因而不可用（最通常的情况是因为IPv6暂不被支持），Kestrel将记录下一个警告信息。 Unix socket

1
http://unix:/run/dan-live.sock

  如果你指定了端口号0，Kestrel将动态地绑定到合适的端口号。除了localhost名称，绑定到0端口号被其他任何主机名称或IP地址所允许。 当你指定了端口号0，你可以使用IServerAddressesFeature接口去决定运行时Kestrel实际绑定到哪个端口。下列示例用于获取绑定端口并且在console上显示出来。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
public void Configure(IApplicationBuilder app, ILoggerFactory loggerFactory)
{
    loggerFactory.AddConsole();
 
    var serverAddressesFeature = app.ServerFeatures.Get<IServerAddressesFeature>();
 
    app.UseStaticFiles();
 
    app.Run(async (context) =>
    {
        context.Response.ContentType = "text/html";
        await context.Response
            .WriteAsync("<p>Hosted by Kestrel</p>");
 
        if (serverAddressesFeature != null)
        {
            await context.Response
                .WriteAsync("<p>Listening on the following addresses: " +
                    string.Join(", ", serverAddressesFeature.Addresses) +
                    "</p>");
        }
 
        await context.Response.WriteAsync($"<p>Request URL: {context.Request.GetDisplayUrl()}<p>");
    });
}

  SSL的URL前缀 如果你调用UseSSL扩展方法，请确保在https:中包含URL前缀，如下所示：

1
2
3
4
5
6
7
8
9
var host = new WebHostBuilder()
    .UseKestrel(options =>
    {
        options.UseHttps("testCert.pfx", "testPassword");
    })
   .UseUrls("http://localhost:5000", "https://localhost:5001")
   .UseContentRoot(Directory.GetCurrentDirectory())
   .UseStartup<Startup>()
   .Build();

  Note HTTPS和HTTP不能在同一端口上被托管。 下一步 更多的信息，请参考以下资源： Sample app for this […]

龙生   25 Mar 2018
View Details

修改PHP上传文件大小限制的方法

1、首先打开php.ini文件，修改post_max_size设定POST数据所允许的最大限制值，php中默认post_max_size=2M；在php.in文件中按Ctrl+F，然后输入post_max_size，找到post_max_size将其改为自己需要上传限制文件的大小，比如改为post_max_size=300M； 2、修改完之后并不能上传较大的文件，则继续修改php.ini中的参数upload_max_filesize，其表示为上传文件的最大值。默认值upload_max_filesize=8M，修改为upload_max_filesize=300M； 3、如果上传仍然有问题，则继续修改。可能跟上传时间有关系。找到php.ini文件中的max_execution_time，默认值max_execution_time=30，其意思就是该页面最长执行的时间为30s，30s之后则上传停止，从而导致上传失败。修改为max_execution_time=0；0表示没有限制。 附：      另外要注意的是,post_max_size 应该大于upload_max_filesize 。 from:https://blog.csdn.net/rision666/article/details/51590803

龙生   25 Mar 2018
View Details

修改Nginx与Apache上传文件大小限制

一、修改Nginx上传文件大小限制 我们使用ngnix做web server的时候，nginx对上传文件的大小有限制。 当超过大小的时候会报413错误。 这个时候我们要修改nginx参数。

1
2
3
4
5
sudo vim /etc/nginx/nginx.conf
 
<strong>在http段里面添加:</strong>
 
client_max_body_size 100m;   //举例设置上传最大值为100m

然后重启nginx

1
systemctl restart nginx

    二、修改Apache上传文件最大值限制 打开php.ini， :/ 找到下面的项并修改之。下面以上传100M为例。

1
sudo vim /etc/php.ini

 

1
2
3
4
5
6
7
file_uploads = on ;是否允许通过HTTP上传文件的开关。默认为ON即是开
 
upload_tmp_dir ;文件上传至服务器上存储临时文件的地方，如果没指定就会用系统默认的临时文件夹
 
upload_max_filesize = 100m ;望文生意，即允许上传文件大小的最大值。默认为2M
 
post_max_size = 100M ;指通过表单POST给PHP的所能接收的最大值，包括表单里的所有值。默认为8M <span class="cnblogs_code_copy"><a title="复制代码"><img src="//longsheng.org/wp-content/uploads/2018/03/copycode.gif" alt="复制代码" /></a></span>

一般地，设置好上述四个参数后，上传<=8M的文件是不成问题，在网络正常的情况下。 但如果要上传>8M的大体积文件，只设置上述四项还一定能行的通。除非你的网络真有100M/S的上传高速，否则你还得关心关心下面的参数：

1
2
3
4
5
max_execution_time = 600 ;每个PHP页面运行的最大时间值(秒)，默认30秒
 
max_input_time = 600 ;每个PHP页面接收数据所需的最大时间，默认60秒
 
memory_limit = 128M ;每个PHP页面所吃掉的最大内存，默认8M

  全部设置好之后，重启

1
systemctl restart httpd

  https://www.cnblogs.com/shifu204/p/6548635.html

龙生   25 Mar 2018
View Details
1 … 207 208 209 … 415