目录 一、EasyUI 二、DWZ JUI 三、HUI 四、BUI 五、Ace Admin 六、Metronic 七、H+ UI 八、Admin LTE 九、INSPINIA 十、LigerUI 十一、其它UI 十二、总结 最近要做一个企业的OA系统，以前一直使用EasyUI，一切都好，但感觉有点土了，想换成现在流行的Bootstrap为基础的后台UI风格，想满足的条件应该达到如下几个： 1、美观、大方、简洁 2、兼容IE8、不考虑兼容IE6/IE7，因为现在还有很多公司在使用Win7系统，系统内置了IE8 3、能通过选项卡打开多个页面，不想做单页，iframe也没关系 4、性能好，不要太笨重 5、最好以Bootstrap为基础 6、还希望在以后别的系统中能够复用。 一次次反复纠结的选择开始了，给大家介绍下我考虑过的UI，也给大家一个参考。 一、EasyUI easyui是一种基于jQuery的用户界面插件集合。 easyui为创建现代化，互动，JavaScript应用程序，提供必要的功能。 使用easyui你不需要写很多代码，你只需要通过编写一些简单HTML标记，就可以定义用户界面。 easyui是个完美支持HTML5网页的完整框架。 easyui节省您网页开发的时间和规模。 easyui很简单但功能强大的。 优点：轻量、功能强大、免费、兼容性好、帮助详细、使用的人多生态好 缺点：非响应式布局、某些系统看起来有点土（客户与老板的感觉、确实与最新的那些UI有差距） 获得：上网搜索、网盘搜索大把被搭建好了基础功能的框架。下载 下载后大家可以替换成最新的1.5版的easyui 官网：http://www.jeasyui.com/，有免费版，有商业版，商业版收费，帮助非常详尽 资源：http://www.jeasyui.net/，easyui是国人的的作品，但服务器在国外，官网也是英文的，这个网站类似官网的中文版 二、DWZ JUI 特点：DWZ富客户端框架(jQuery RIA framework), 是中国人自己开发的基于jQuery实现的Ajax RIA开源框架. 设计目标是简单实用,快速开发,降低ajax开发成本。 官网：http://jui.org/ 下载：https://github.com/dwzteam/ 三、HUI H-ui前端框架是在bootstrap的思想基础上基于 HTML、CSS、JAVASCRIPT开发的轻量级web前端框架,开源免费,简单灵活,兼容性好,满足大多数中国网站。分了前端UI与后端UI。 官网：http://www.h-ui.net/H-ui.admin.shtml 后台，http://www.h-ui.net/ 前台 下载：https://github.com/jackying/ 缺点：感觉用的人少，名气小，资料不全，配套组件不多，但国人的产品符合国人的口味。 四、BUI BUI她是基于jQuery,兼容KISSY的UI类库，专致于解决后台系统的框架方案，BUI提供了丰富的DPL含有强大的控件库对业务做了精细的分析。 官网：http://www.builive.com/ 下载：https://github.com/dxq613/bui 感觉也比较冷、与HUI有点类似的优点整体框架符合我的要求，但风格有种说不出的感觉。 五、Ace Admin 响应式Bootstrap网站后台管理系统模板ace admin，非常不错的轻量级易用的admin后台管理系统，基于Bootstrap3，拥有强大的功能组件以及UI组件，基本能满足后台管理系统的需求，而且能根据不同设备适配显示，而且还有四个主题可以切换。以前收费，好像最新版不再收费了。 下载：https://github.com/bopoda/ace 官网：http://ace.jeka.by/ 感觉比较全，功能强大,组件多，美观，只是用了很多不同的插件，兼容性不错。 兼容的浏览器： Internet Explorer 10 Internet Explorer 11 Internet Explorer 8 Internet Explorer 9 Latest Chrome Latest Firefox Latest Opera Latest Safari 使用的插件： jQuery 2.0.3 jQuery UI 1.10.3 (Custom Build) Twitter Bootstrap 3.0.0 FontAwesome 3.2.1 Google "Open Sans" Font jQuery Flot Charts 0.8.1 jQuery Sparklines 2.1.2 Easy Pie Chart 1.2.5 jQuery Knob 1.2.0 jQuery Validate 1.11.1 FuelUX 2.3.0 (Spinner & Wizard & Treeview) FullCalendar 1.6.4 jQuery ColorBox 1.4.27 jQuery dataTables 1.9.4 jQuery Chosen 1.0 jQuery Masked Input 1.3.1 jQuery Input Limiter 1.3.1 jQuery AutoSize 1.17.7 Bootstrap Colorpicker Bootstrap Datepicker Bootstrap Timepicker v0.2.3 Bootstrap DateRange Picker 1.2 Bootbox.js 4.0.0 jQuery Gritter 1.7.4 jQuery slimScroll 1.1.1 Spin.js 1.3.0 jQuery UI Touch Punch 0.2.2 Google Code Prettify ExplorerCanvas Mindmup Wysiwyg Editor Toopay Markdown Editor 1.1.4 X-editable 1.4.6 Select2 3.4.2 Bootstrap Tags 2.2.5 jQuery Mobile 1.3.2 (Custom Build) jqGrid 4.5.2 Dropzone.js 3.0 Nestable lists plugin View Code 使用到的插件并没有分开存放，使用起来会麻烦一些。 另外该插件也被很多人简化、修改成选项卡+iframe风格了。 六、Metronic Metronic 是一套精美的响应式后台管理模板，基于强大的 Twitter Bootstrap 框架实现。Metronic 拥有简洁优雅的 Metro UI 风格界面，6 种颜色可选，76 个模板页面，包括图表、表格、地图、消息中心、监控面板等后台管理项目所需的各种组件。 页面规范、精致、细腻、美观大方；功能强大、非常全；在所有我看到过的基于Bootstrap的网站模版中，Metronic是我认为最优秀的之一，其外观之友好、功能之全面让人惊叹。Metronic 是一个自适应的HTML模版，提供后台管理模版和前端内容网页模版两种风格。 优点： 支持HTML5 和 CSS3自适应，基于响应式 Twitter Bootstrap框架，同时面向桌面电脑、平板、手机等终端。整合AngularJS 框架。可自定义管理面板，包括灵活的布局、主题、导航菜单、侧边栏等。提供了部分电子商务模块：CMS, CRM, SAAS。多风格，提供了3个前端风格，7个后端管理面板风格。简洁扁平风格设计。700多个网页模版，1500多个UI小组件，100多个表单，80多个jQuery插件。提供说明文档。 缺点： 太大了，真的不知道从那里开始 对IE的兼容不好，虽然官方声称支持IE8，但我测试结果不支持 收费，今天的价格是$28 七、H+ UI 官网的介绍：H+是一个完全响应式，基于Bootstrap3.3.6最新版本开发的扁平化主题，她采用了主流的左右两栏式布局，使用了Html5+CSS3等现代技术，她提供了诸多的强大的可以重新组合的UI组件，并集成了最新的jQuery版本(v2.1.4)，当然，也集成了很多功能强大，用途广泛的jQuery插件，她可以用于所有的Web应用程序，如网站管理后台，网站会员中心，CMS，CRM，OA等等，当然，您也可以对她进行深度定制，以做出更强系统。 官网：http://www.zi-han.net/theme/hplus/ 与Metronic与INSPINIA非常像，插件非常多，收费998人民币。 八、Admin LTE AdminLTE 是一个基于Bootstrap 3.x的免费主题，它是一个完全响应式管理模板。高度可定制的，易于使用。适合从小型移动设备到大的台式机很多的屏幕分辨率。 下载：https://github.com/almasaeed2010/AdminLTE （目前star 11652+） 预览: http://almsaeedstudio.com/preview/ 官网：Free Bootstrap Admin Template 浏览器支持：IE 9+Firefox (latest)Chrome (latest)Safari (latest)Opera (latest) 插件： Boostrap Slider Ion slider Bootstrap WYSIHTML5 CKEditor Bootstrap Colorpicker Bootstrap Date range Picker Bootstrap Time Picker Data Tables Flot Morris.js Sparkilne Full Calendar iCheck jQuery input mask jQuery Knob jVector Map Slim Scroll Pace Bootstrap Social Buttons View Code 特点： 响应式布局，支持多种设备 打印增强 丰富可排序的面板组件 18个插件与3个自定义插件 轻量、快速 兼容主流浏览器，IE8不兼容 支持Glyphicons, Fontawesome和Ion图标 整体感觉与Metronic类似、功能强大，UI精致，被许多公司使用。 评论中感谢网友（dotNetDR_、醉丶千秋）推荐，确定是值得关注的一个UI。 九、INSPINIA INSPINIA是平面设计理念的管理模板。它是充分响应的由Bootstrap3 +框架开发的模板,HTML5和CSS3。它有很多可重用的UI组件和集成了最新的jQuery插件。它可以用于所有类型的web应用程序自定义管理面板中,项目管理系统,管理仪表板,应用程序的后端,CMS或CRM。 与Metronic一样，风格也比较像，个人认为比Metronic还要强大一些，页面规范、精致、细腻、美观大方；功能强大、非常全；在所有我看到过的基于Bootstrap的网站模版中，Metronic是我认为最优秀的之一，其外观之友好、功能之全面让人惊叹。Metronic 是一个自适应的HTML模版，提供后台管理模版和前端内容网页模版两种风格。 浏览器兼容： IE 9, 10, 11 Latest Chrome Latest Firefox Latest Opera Latest Safari 收费，今天的价格是$18。 演示地址：http://wrapbootstrap.com/preview/WB0R5L90S 特点： 相对Metronic他准备了很多个版本，比如： Static version, AngularJS, ASP.NET MVC5/MVC6, Meteor and Ruby on Rails version 插件很多，但都按引用分文件夹存放了，静态版本中我看了就是48个插件，有PSD源文件，提供的文件包含： Static Full Version Static Seed Project MVC5 Full Version MVC5 Seed Project MVC6 Full Version (.NET RC1) MVC6 Seed Project (.NET RC1) Ruby on Rails Full Version Ruby on Rails Seed Project Meteor Full Version Meteor Seed Project Angular Full Version Angular Seed Project Angular Seed Project Grunt Angular Seed Project Gulp Angular Seed Project MEANJS Documentation Landing Page LESS SASS SCSS PSD Files (more than 20 main views and components full layered) View Code 详细介绍：https://wrapbootstrap.com/theme/inspinia-responsive-admin-theme-WB0R5L90S 十、LigerUI LigerUI 是基于jQuery 的UI框架，其核心设计目标是快速开发、使用简单、功能强大、轻量级、易扩展。简单而又强大，致力于快速打造Web前端界面解决方案，可以应用于.net,jsp,php等等web服务器环境。 官网：http://www.ligerui.com/ 演示：http://www.ligerui.com/demo.html 特点： 使用简单，轻量级控件实用性强，功能覆盖面大，可以解决大部分企业信息应用的设计场景快速开发，使用LigerUI可以比传统开发减少极大的代码量易扩展，包括默认参数、表单/表格编辑器、多语言支持等等支持Java、.NET、PHP等web服务端支持 IE6+、Chrome、FireFox等浏览器开源，源码框架层次简单易懂。 下载：http://pan.baidu.com/s/1o83vRZk API: http://api.ligerui.com/ 演示地址: http://demo.ligerui.com/ 源码下载: http://git.oschina.net/ligerui/LigerUI/ (源码托管) 　　　　　http://pan.baidu.com/s/1D0AVO (V1.2.3) 技术支持： http://www.cnblogs.com/leoxie2011/ 个人感觉文档比较全，也有公司的信息系统使用了该UI（去年我去一家公司培训他们就使用该UI，后面上头说要换漂亮些的，他们纠结好久），但整合感觉比不上EasyUI，与DotNet亲一点感觉，DWZ则与Java新一些。 LigerUI中国人开发的、免费。 十一、其它UI 十二、总结 没有形式就没有内容、UI重要，特别是当客户与老板不懂太多关于代码、功能、性能的时候。 上面的UI你也许可以通过各种途径获得，但商业应用请慎重。 想来想去还是拿不定主意，不过有点想法： 1、使用HUI和bootstrap 2、使用EasyUI的框架，内容页使用HUI+BootStrap，iframe选项卡 3、从各个功能强大的页面中拿一些插件过来 http://www.cnblogs.com/best/p/5782891.html  

目录 一、EasyUI 二、DWZ JUI 三、HUI 四、BUI 五、Ace Admin 六、Metronic 七、H+ UI 八、Admin LTE 九、INSPINIA 十、LigerUI 十一、其它UI 十二、总结 最近要做一个企业的OA系统，以前一直使用EasyUI，一切都好，但感觉有点土了，想换成现在流行的Bootstrap为基础的后台UI风格，想满足的条件应该达到如下几个： 1、美观、大方、简洁 2、兼容IE8、不考虑兼容IE6/IE7，因为现在还有很多公司在使用Win7系统，系统内置了IE8 3、能通过选项卡打开多个页面，不想做单页，iframe也没关系 4、性能好，不要太笨重 5、最好以Bootstrap为基础 6、还希望在以后别的系统中能够复用。 一次次反复纠结的选择开始了，给大家介绍下我考虑过的UI，也给大家一个参考。   一、EasyUI easyui是一种基于jQuery的用户界面插件集合。 easyui为创建现代化，互动，JavaScript应用程序，提供必要的功能。 使用easyui你不需要写很多代码，你只需要通过编写一些简单HTML标记，就可以定义用户界面。 easyui是个完美支持HTML5网页的完整框架。 easyui节省您网页开发的时间和规模。 easyui很简单但功能强大的。 优点：轻量、功能强大、免费、兼容性好、帮助详细、使用的人多生态好 缺点：非响应式布局、某些系统看起来有点土（客户与老板的感觉、确实与最新的那些UI有差距） 获得：上网搜索、网盘搜索大把被搭建好了基础功能的框架。下载 下载后大家可以替换成最新的1.5版的easyui 官网：http://www.jeasyui.com/，有免费版，有商业版，商业版收费，帮助非常详尽 资源：http://www.jeasyui.net/，easyui是国人的的作品，但服务器在国外，官网也是英文的，这个网站类似官网的中文版   二、DWZ JUI 特点：DWZ富客户端框架(jQuery RIA framework), 是中国人自己开发的基于jQuery实现的Ajax RIA开源框架. 设计目标是简单实用,快速开发,降低ajax开发成本。 官网：http://jui.org/ 下载：https://github.com/dwzteam/   三、HUI H-ui前端框架是在bootstrap的思想基础上基于 HTML、CSS、JAVASCRIPT开发的轻量级web前端框架,开源免费,简单灵活,兼容性好,满足大多数中国网站。分了前端UI与后端UI。 官网：http://www.h-ui.net/H-ui.admin.shtml 后台，http://www.h-ui.net/ 前台 下载：https://github.com/jackying/ 缺点：感觉用的人少，名气小，资料不全，配套组件不多，但国人的产品符合国人的口味。   四、BUI BUI她是基于jQuery,兼容KISSY的UI类库，专致于解决后台系统的框架方案，BUI提供了丰富的DPL含有强大的控件库对业务做了精细的分析。 官网：http://www.builive.com/ 下载：https://github.com/dxq613/bui 感觉也比较冷、与HUI有点类似的优点整体框架符合我的要求，但风格有种说不出的感觉。   五、Ace Admin 响应式Bootstrap网站后台管理系统模板ace admin，非常不错的轻量级易用的admin后台管理系统，基于Bootstrap3，拥有强大的功能组件以及UI组件，基本能满足后台管理系统的需求，而且能根据不同设备适配显示，而且还有四个主题可以切换。以前收费，好像最新版不再收费了。 下载：https://github.com/bopoda/ace 官网：http://ace.jeka.by/ 感觉比较全，功能强大,组件多，美观，只是用了很多不同的插件，兼容性不错。 兼容的浏览器： Internet Explorer 10 Internet Explorer 11 Internet Explorer 8 Internet Explorer 9 Latest Chrome Latest Firefox Latest Opera Latest Safari 使用的插件： View Code 使用到的插件并没有分开存放，使用起来会麻烦一些。 另外该插件也被很多人简化、修改成选项卡+iframe风格了。   六、Metronic Metronic 是一套精美的响应式后台管理模板，基于强大的 Twitter Bootstrap 框架实现。Metronic 拥有简洁优雅的 Metro UI 风格界面，6 种颜色可选，76 个模板页面，包括图表、表格、地图、消息中心、监控面板等后台管理项目所需的各种组件。 页面规范、精致、细腻、美观大方；功能强大、非常全；在所有我看到过的基于Bootstrap的网站模版中，Metronic是我认为最优秀的之一，其外观之友好、功能之全面让人惊叹。Metronic 是一个自适应的HTML模版，提供后台管理模版和前端内容网页模版两种风格。 优点： 支持HTML5 和 CSS3 自适应，基于响应式 Twitter Bootstrap框架，同时面向桌面电脑、平板、手机等终端。 整合AngularJS 框架。 可自定义管理面板，包括灵活的布局、主题、导航菜单、侧边栏等。 提供了部分电子商务模块：CMS, CRM, SAAS。 多风格，提供了3个前端风格，7个后端管理面板风格。 简洁扁平风格设计。 700多个网页模版，1500多个UI小组件，100多个表单，80多个jQuery插件。 提供说明文档。 缺点： 太大了，真的不知道从那里开始 对IE的兼容不好，虽然官方声称支持IE8，但我测试结果不支持 收费，今天的价格是$28   七、H+ UI 官网的介绍：H+是一个完全响应式，基于Bootstrap3.3.6最新版本开发的扁平化主题，她采用了主流的左右两栏式布局，使用了Html5+CSS3等现代技术，她提供了诸多的强大的可以重新组合的UI组件，并集成了最新的jQuery版本(v2.1.4)，当然，也集成了很多功能强大，用途广泛的jQuery插件，她可以用于所有的Web应用程序，如网站管理后台，网站会员中心，CMS，CRM，OA等等，当然，您也可以对她进行深度定制，以做出更强系统。 官网：http://www.zi-han.net/theme/hplus/ 与Metronic与INSPINIA非常像，插件非常多，收费998人民币。   八、Admin LTE AdminLTE 是一个基于Bootstrap 3.x的免费主题，它是一个完全响应式管理模板。高度可定制的，易于使用。适合从小型移动设备到大的台式机很多的屏幕分辨率。 下载：https://github.com/almasaeed2010/AdminLTE （目前star 11652+） 预览: http://almsaeedstudio.com/preview/ 官网：Free Bootstrap Admin Template 浏览器支持： IE 9+ Firefox (latest) Chrome (latest) Safari (latest) Opera (latest) 插件： View Code 特点： 响应式布局，支持多种设备 打印增强 丰富可排序的面板组件 18个插件与3个自定义插件 轻量、快速 兼容主流浏览器，IE8不兼容 支持Glyphicons, Fontawesome和Ion图标 整体感觉与Metronic类似、功能强大，UI精致，被许多公司使用。 评论中感谢网友（dotNetDR_、醉丶千秋）推荐，确定是值得关注的一个UI。   九、INSPINIA INSPINIA是平面设计理念的管理模板。它是充分响应的由Bootstrap3 +框架开发的模板,HTML5和CSS3。它有很多可重用的UI组件和集成了最新的jQuery插件。它可以用于所有类型的web应用程序自定义管理面板中,项目管理系统,管理仪表板,应用程序的后端,CMS或CRM。 与Metronic一样，风格也比较像，个人认为比Metronic还要强大一些，页面规范、精致、细腻、美观大方；功能强大、非常全；在所有我看到过的基于Bootstrap的网站模版中，Metronic是我认为最优秀的之一，其外观之友好、功能之全面让人惊叹。Metronic 是一个自适应的HTML模版，提供后台管理模版和前端内容网页模版两种风格。 浏览器兼容： IE 9, 10, 11 Latest Chrome Latest Firefox Latest Opera Latest Safari 收费，今天的价格是$18。 演示地址：http://wrapbootstrap.com/preview/WB0R5L90S 特点： 相对Metronic他准备了很多个版本，比如： Static version, AngularJS, ASP.NET MVC5/MVC6, Meteor and Ruby on Rails version 插件很多，但都按引用分文件夹存放了，静态版本中我看了就是48个插件，有PSD源文件，提供的文件包含： View Code 详细介绍：https://wrapbootstrap.com/theme/inspinia-responsive-admin-theme-WB0R5L90S   十、LigerUI LigerUI 是基于jQuery 的UI框架，其核心设计目标是快速开发、使用简单、功能强大、轻量级、易扩展。简单而又强大，致力于快速打造Web前端界面解决方案，可以应用于.net,jsp,php等等web服务器环境。   官网：http://www.ligerui.com/ 演示：http://www.ligerui.com/demo.html 特点： 使用简单，轻量级 控件实用性强，功能覆盖面大，可以解决大部分企业信息应用的设计场景 快速开发，使用LigerUI可以比传统开发减少极大的代码量 易扩展，包括默认参数、表单/表格编辑器、多语言支持等等 支持Java、.NET、PHP等web服务端 支持 IE6+、Chrome、FireFox等浏览器 开源，源码框架层次简单易懂。 下载：http://pan.baidu.com/s/1o83vRZk API:         http://api.ligerui.com/ 演示地址:  http://demo.ligerui.com/ 源码下载:  http://git.oschina.net/ligerui/LigerUI/ (源码托管) 　　　　　http://pan.baidu.com/s/1D0AVO (V1.2.3) 技术支持： http://www.cnblogs.com/leoxie2011/ 个人感觉文档比较全，也有公司的信息系统使用了该UI（去年我去一家公司培训他们就使用该UI，后面上头说要换漂亮些的，他们纠结好久），但整合感觉比不上EasyUI，与DotNet亲一点感觉，DWZ则与Java新一些。 LigerUI中国人开发的、免费。   十一、其它UI   十二、总结 没有形式就没有内容、UI重要，特别是当客户与老板不懂太多关于代码、功能、性能的时候。 上面的UI你也许可以通过各种途径获得，但商业应用请慎重。 想来想去还是拿不定主意，不过有点想法： 1、使用HUI和bootstrap 2、使用EasyUI的框架，内容页使用HUI+BootStrap，iframe选项卡 3、从各个功能强大的页面中拿一些插件过来

当今从纯网站技术上来说，因为开源模式的发展，现在建一个小网站已经很简单也很便宜，所以很多人都把创业方向定位在互联网应用。这些人里大多数不是很懂技术，或者不是那么精通，而网站开发维护方面的知识又很分散，学习成本太高，所以这篇文章将这些知识点结合起来，系统的来说，一个从日几千访问的小小网站，到日访问一两百万的小网站，中间可能会产生什么问题，以及怎么才能在一开始做足工作尽量避免这些问题。 相关厂商内容 大众点评主架构师吴其敏，将会在QCon分享大众点评网监控平台经验 Tumblr平台工程总监 Blake，确认参与QCon，分享Tumblr的架构演进 eBay与PayPal的5位全球专家，确认QCon分享主题：大数据分析和电商云计算 创业者之“翼”选拔大赛9月8日火爆开启！ 百度技术沙龙第三十一期：推荐引擎算法与技术（10月20日 周六） 相关赞助商 QCon杭州2012大会10月25~27，最后两周，票量有限，欲购从速，5人以上团购享有更多优惠！         你的网站因为努力经营，访问量逐渐升高，在升高的过程中，问题也可能开始显现了。因为带宽的增加、硬件的扩展、人员的扩张所带来的成本提高是显而易见的，而还有相当大的一部分成本是因为代码重构、架构重构，甚至底层开发语言更换引起的，最坏的情况就是数据丢失，所有努力付之一炬。这类成本支出大多数在一开始就可以避免，先打好基础，往后可以省很多精力，少操很多心。 对于不同的初期投资成本，技术路线的选择是不同的。这里假设网站刚刚只是一个构想，计划第一年服务器硬件带宽投入5万左右。对于这个资金额度，有很多种方案可选择，例如租用虚拟主机、租用单独服务器，或者流行的私有云，或者托管服务器。前两种选择，网站发展到一定规模时需迁移，那时再重做规划显然影响更大。服务器托管因为配置自主、能完全掌握控制权，所以有一定规模的网站基本都是这种模式。采用自己托管服务器的网站，一开始要注意以下几点—— 一、开发语言 一般来说，技术人员（程序员）都是根据自己技术背景选择自己最熟悉的语言，不过不可能永远是一个人写程序，所以在语言的选择上还要是要费些心思。首先明确一点，无论用什么语言，最终代码质量是看管理，因此我们从前期开发成本分析。现在国内流行的适用于网站的语言，大概有java、php、.net、python、ruby这五大阵营。python和ruby因为在国内流行的比较晚，现在人员还是相对难招一些。.net平台的人相对多，但是到后期需要解决性能问题时，对人员技能的要求比较高。剩余的java、php用人可以说是最多的。java和php无法从语言层面做比较，但对于初期，应用几乎都是靠前端支撑的网站来说，php入门简单、编写快速，优势相对大一点。至于后端例如行为分析、银行接口、异步消息处理等，等真正需要时，就要根据不同业务需求来选择不同语言了。 二、代码版本管理 稍微有点规模的网站就需要使用代码版本管理了。代码版本管理两点最大的好处，一是方便协同工作，二是有历史记录可查询比较。代码版本管理软件有很多，vss/cvs/svn/hg等，目前国内都比较流行，其中svn的普及度还是很高的。 假设选了svn，那么有几点考虑。一是采用什么树结构。初期可能只有一条主干，往后就需要建立分支，例如一条开发分支，一条上线分支，再往后，可能要每个小组一个分支。建议一开始人少时选择两条分支，开发和线上，每个功能本地测试无误后提交到开发分支，最后统一测试，可以上线时合并到上线分支。如果每人都建自己的分支，合并时会浪费很大精力，对于几乎每天都要修改几次的WEB应用来说，所费时间太多。 向服务器部署代码，可以手工部署也可以自动部署。手工部署相对简单，一般可直接在服务器上svn update，或者找个新目录svn checkout，再把web root给ln -s过去。应用越复杂，部署越复杂，没有什么统一标准，只是别再用ftp上传那种形式，一是上传时文件引用不一致错误率增加，二是很容易出现开发人员的版本跟线上版本不一致，导致本来想改个错字结果变成回滚。如果有多台服务器还是建议自动部署，更换代码的机器从当前服务池中临时撤出，更新完毕后再重新加入。 三、服务器硬件 在各个机房里，靠一台服务器孤独支撑的网站数不清，但如果资金稍微充足，建议至少三台的标准配置，分别用作web处理、数据库、备份。web服务器至少要8G内存，双sata raid1，如果经济稍微宽松，或静态文件或图片多，则15k sas raid10。数据库至少16G内存，15k sas raid 10。备份服务器最好跟数据库服务器同等配置。硬件可以上整套品牌，也可以兼容机，也可以半品牌半组装，取决于经济能力。当然，这是典型的搭配，有些类型应用的性能瓶颈首先出现在web上，那种情况就要单独分析了。 web服务器可以既跑程序又当内存缓存，数据库服务器则只跑主数据库（假如是MySQL的话），备份服务器所承担就相对多一些，web配置、缓存配置、数据库配置都要跟前两台一致，这样WEB和数据库任意一台出问题，很容易就可以将备份服务器切换过去临时顶替，直到解决完问题。要注意，硬件是随时可能坏掉的，特别是硬盘，所以宁可WEB服务器跟数据库服务器放在一起，也一定不能省掉备份，备份一定要异机，并且有异步，电力故障、误操作都可能导致一台机器上的所有数据丢失。很多的开源备份方案可选择，最简单的就是rsync，写crontab里，定时同步。备份和切换，建议多做测试，选最安全最适合业务的，并且尽可能异地备份。 四、机房 三种机房尽量不要选：联通访问特别慢的电信机房、电信访问特别慢的联通机房、电信联通访问特别慢的移动或铁通机房。机房要尽可能多的实地参观，多测试，找个网络质量好，管理严格的机房。机房可以说是非常重要，直接关系到网站访问速度，网站访问速度直接关系到用户体验，访问速度很慢的网站，很难获得用户青睐。 五、架构 在大方向上，被熟知的架构是web负载均衡+数据库主从+缓存+分布式存储+队列。在一开始，按照可扩展的原则设计和编程就可以。只是要多考虑缓存失效时的雪崩效应、主从同步的数据一致性和时间差、队列的稳定性和失败后的重试策略、文件存储的效率和备份方式等等意外情况。缓存失效、数据库复制中断、队列写入错误、电源损坏，在实际运维中经常发生，如果不注意这些，出现问题时恢复期可能会超出预期很长时间。 六、服务器软件 操作系统Linux很流行。在没有专业运维人员的情况下，应倾向于择使用的人多、社区活跃、配置方便、升级方便的发行版，例如RH系列、debian、ubuntu server等，硬件和操作系统要一起选择，看是否有适合的驱动，如果确定用某种商业软件或解决方案，也要提前知晓其对哪种操作系统支持最佳。web服务器方面，apache、nginx、lighttpd三大系列中，apache占有量还是最大，但是想把性能调教好还是需要很专业的，nginx和lighttpd在不需要太多调整的情况下可以达到一个比较不错的性能。无论选择什么软件，除非改过这些软件或你的程序真的不兼容新版本，否则尽量版本越新越好，版本新，意味着新特性增多、BUG减少、性能增加。一个典型的php网站，基本上大多数人都没改过任何服务器软件源代码，绝大多数情况是能平稳的升级到新版本的。类似于jdk5到 jdk6，python2到python3这类变动比较大的升级还是比较少见的。看看ChangeLog，看看升级说明，结合自己情况评估测试一下，越早升级越好，升级的越晚，所花费的成本越高。对于软件包，尽量使用发行版内置的包管理工具，没有特殊要求时不建议自己编译，那样对将来运维不利。 七、数据库 几乎所有操作最后都要落到数据库身上，它又最难扩展（存储也挺难）。数据库常见的扩展方法有复制、分片，设计时要考虑到每种应用的数据如何复制、分片，当然这种考虑一般会推迟到技术设计时期。在初期进行数据库结构设计时，要根据不同的业务类型和增长量预期来考虑是否要分库、分区，并且尽量不要使用联合查询、不使用自增ID以方便分片。复制延时问题、主从数据库数据一致性问题，可以自己写或者用已有的运维工具进行检测。 用存储过程是比较难扩展的，这种情形多发生于传统C/S，特别是OA系统转换过来的开发人员。低成本网站不是一两台小型机跑一个数据库处理所有业务的模式，是机海作战。方便水平扩展比那点预分析时间和网络传输流量要重要的多的多。 另外，现在流行一种概念叫NoSQL，可以理解为非传统关系型数据库。实际应用中，网站有着越来越多的密集写操作、上亿的简单关系数据读取、热备等，这都不是传统关系数据库所擅长的，于是就产生了很多非关系型数据库，比如Redis/TC&TT/MongoDB/Memcachedb等，在测试中，这些几乎都达到了每秒至少一万次的写操作，内存型的甚至5万以上。在设计时，可根据业务特点和性能要求来选择是否使用这类数据库。例如MongoDB，几句配置就可以组建一个复制+自动分片+failover的环境，文档化的存储也简化了传统设计库结构再开发的模式。但是当你决定采用一项技术时，一定要真正了解其优劣，例如可能你所选择的技术并不能支持你所需要的事务和数据一致性要求。 八、文件存储 存储的分布几乎跟数据库扩展一样困难，不过只有百万的PV的情况下，磁盘IO方面一般不会成大问题，一两台采用SATA做条带RAID的机器可以应付，反而是自己做异步备份比较复杂，因为小文件多。如果只有一台机器做存储，可以做简单的优化，例如放最小缩略图的分区和放中等缩略图的分区，根据平均大小调整一下块大小。存储要规划好目录结构，否则文件增多后维护起来复杂，也不利于扩展。同时还要考虑将来扩容，例如采用LVM，或者把文件根据不同规则散列到不同机器。磁盘IO繁重的情况下更容易出现故障，所以要做好备份，若发现有盘坏掉，要马上行动更换，很多人的硬盘都是坏了一块之后，接二连三的坏下去。 为了将来图片走cdn做准备，一开始最好就将图片的域名分开，且不用主域名。因为很多网站都将cookie设置到了.domain.ltd，如果图片也在这个域名下，很可能因为cookie而造成缓存失效，并且占多余流量，还可能因为浏览器并发线程限制造成访问缓慢。 九、程序 一定硬件条件下，应用能承载多少访问量，很大一部分也取决于程序如何写。程序写的不好，可能一万的访问都承载不了，写的好，可能一两台机器就能承担几百万PV。越是复杂、数据实时性要求越高的应用，优化起来越难，但对普通网站有一个统一的思路，就是尽量向前端优化、减少数据库操作、减少磁盘IO。向前端优化指的是，在不影响功能和体验的情况下，能在浏览器执行的不要在服务端执行，能在缓存服务器上直接返回的不要到应用服务器，程序能直接取得的结果不要到外部取得，本机内能取得的数据不要到远程取，内存能取到的不要到磁盘取，缓存中有的不要去数据库查询。减少数据库操作指减少更新次数、缓存结果减少查询次数、将数据库执行的操作尽可能的让你的程序完成（例如join查询），减少磁盘IO指尽量不使用文件系统作为缓存、减少读写文件次数等。程序优化永远要优化慢的部分，换语法是无法“优化”的。 然而编程时不应该把重点放在优化上，应该关注扩展性。当今的WEB应用，需求变化非常之快，适应多种需求的架构是不存在的，我们的扩展性就要把要点放在跟底层交互的架构上，例如持久化数据的存取规则、缓存的存取规则等，还有一些共用服务，例如用户信息等。先把不变的部分做完善，剩下的部分就很容易将精力放在业务逻辑上面了。 本文摘至 http://www.infoq.com/cn/articles/lzy-million-visits-site-technical-preparations

本文将阿里云运维实践汇总为十八招，从云时代下的资源自动化管理，到静态、动态缓存提升网站性能的方法，再到混合云架构、互联网监控解决方案，以及Devops和云安全实践等，都是比较经典的一些干货，让大家了解阿里云最热门的运维架构技术实践。 直播视频回放，戳这里 想看，降云十八掌——阿里云运维架构最佳实践（上），戳这里。 第十招 使用动态缓存提升网站性能的四种方法 说完静态缓存，当然也有动态缓存。降云十八掌的第十招——使用动态缓存提升网站性能的四种方法。动态缓存，即asp、jsp、php等动态请求页面缓存，所以对数据展示实时性要求高的应用需要慎用。一般一些论坛帖子、用户留言等这些业务数据展示实时性要求并不高，都是可以将这些动态数据缓存。使用动态缓存提升网站性能的四种方法具体如下： 第一种方法，和前面介绍的磁盘缓存采用的技术一样。都是通过nginx的proxy_cache模块，只不过动态缓存中，如图配置，我们在nginx的location中匹配的是jsp等动态请求，然后先从缓存中取，而静态缓存中，匹配的是js、css、html等静态请求，这是它们的核心区别。 第二种方法，就是php自带的fastcgi_cache模块，能对php请求进行缓存。 第三种方法，通过nginx内置memcache模块实现动态页面缓存。我记得之前在一家电商公司做运维的时候，每次到活动量，我发现memcache缓存服务器的流量每秒高达三四百兆。按照那时候的理解，memcache存储热点数据（比如数据库访问的热点数据、或者业务临时数据）怎么会有这么高的流量。然后我通过看nginx的配置文件，发现nginx中配置了连接memcache的配置，nginx好像能对memcache直接进行读取。其实当初真没见过这种用法，我向研发总监请教了这个问题。原来这是nginx自带的memcache模块功能，后端通过业务代码，把订单的拍照图片直接存放至memcache中，前端能直接通过nginx访问memcache中存放的图片信息。 方法四，nginx通过第三方模块实现动态页面缓存的区别在于，方法三在存储图片的时候需要通过编码，将图片等静态数据写到memcache缓存中。而nginx通过第三方模块实现动态页面缓存，是通过第三方模块插件，直接将静态资源数据写到memcache或者redis缓存中。通过图中的架构图，我们也能看到这个差别。 第十一招 混合云架构最佳实践 混合云架构也是当前云端运维架构实践中主流的架构场景实践。混合云架构通过专线能将云上和企业内网、或者IDC数据中心内网打通。所以在异地容灾备份、或者企业级OA、ERP内网应用中应用广泛。 上图中架构就是一个云端客户案例，对数据安全性、对数据异地容灾有很高要求。通过VPC+专线打通两个机房，一个机房用于线下测试及预发环境，一个机房用于热备云上数据。由于云MongoDB没办法和线下做副本集，所以我们采用自建mongo副本集。 Rabbitmq采用镜像复制模式+SLB组成两台机器的高可用。由于都是内网环境，我们自建内网DNS，方便线下IDC测试预发环境及线上环境做内部业务域名定义。由于客户业务代码框架限制，及mysql需要支持myisam表等一些原因，我们在云上和线下采用自建redis及mysql高可用方案。Redis采用主从+sentinel+consul+dnsmasq做高可用。Mysql采用主从+consul+dnsmasq高可用。 第十二招 互联网监控的演变（11种监控解决方案） 监控系统是业务运维保障的眼睛，让业务出现问题、异常能第一时间发现并解决。可以没有自动化，没有DevOps，但是不能没有监控。随着云计算的发展，各种监控技术的成熟，也伴随着互联网监控体系的演变。接下来简要介绍常见的11中监控解决方案，这是降云十八掌中的第十二招。 我们先来看看，物理机体系下的三大监控方案实践监控方案一：Shell/Python，这个监控解决方案一般用于不懂运维的研发人员，没听说过监控系统，也不知道用什么监控系统。所以就用自己擅长的开发语言，来完成日常监控需求。比如我以前做Java开发的时候，兼公司的运维、服务器的监控，就是自己写了几个shell脚本完成。当然，这样缺点也有很多，比如在中间件、应用层监控中，在监控数据存储、数据查看等方面基本都不能做。 监控方案二：Nagios，官方称Nagios为IT基础架构监控的行业标准，主要偏向做主机系统、交换机路由器等网络设备的监控。这是一款80后监控工具，基本上90后很多人都已经不知道nagios了。很多监控的功能通过插件化来实现，对技术能力要求高，并且在图形展示、中间件方面监控较弱。 监控方案三：所以为了解决nagios在图形展示方面的问题，在实际应用中，我们一般把cacti+nagios结合起来。这也是物理机体系下的最佳监控实践。云计算体系有四大监控方案实践，具体如下： 监控方案四：Zabbix，官网称zabbix为企业级IT监控解决方案，相比nagios官网的介绍特点，zabbix既然被称作企业级解决方案，就能看出来zabbix不仅仅能做nagios主机、网络设备层面的监控，在其他企业级其他方面监控需求也可以，比如中间件、日志等都能监控。最为核心的是，zabbix具有完善详细且成熟的API，支持企业级定制化开发，这个功能非常重要，企业可以通过api把zabbix集成在自己的运维自动化平台中，或者基于zabbix二次定制化开发适合公司业务的监控系统。 Zabbix缺点就是面对大数据的冲击，zabbix采用关系型数据库存储监控数据，已经满足不了海量监控数据的存储，还有就是zabbix对容器的支持并不是很好。 监控方案五：云监控，云监控（CloudMonitor） 是一项针对阿里云资源和互联网应用进行监控的服务。随着云平台的普及及发展，监控的趋势主要会偏向云监控。因为云平台会把常见开源环境，比如web、缓存、数据库都会封装产品化。运维人员不需要再去安装部署这些开源类中间件，只需要开通对应产品服务，一键式配置管理维护等。所以我们不需要再自建zabbix等监控需求，云监控一键式的监控设置，能满足80%~90%互联网企业的监控需求。 监控方案六：驻云监控1.0，核心主要基于Zabbix。我们主要累积了金融、电商、游戏等领域的监控模板，并且7×24的监控值班中心保障报警问题能及时触达到运维人员。我们监控值班中心差不多十个人左右7×24轮班，高大上的监控室让人看起来就觉得非常帅气，非常专业。 监控方案七：驻云监控2.0相比1.0，我们继承了云监控的站点监控等功能，弥补zabbix监控体系的不足。并且结合zabbix api，我们研发了阿尔法智能告警系统，直接砍掉了7*24值班人员的监控中心。所有告警通过智能电话，自动的通知运维。接下来进入容器体系，主要有四大监控方案实践，包括： 监控方案八：我们知道，zabbix、nagios是1998、1999年那时候出来的技术，那时候也根本就没有容器技术之类的概念，而prometheus是如今专门为容器监控而生的。Prometheus火热程度仅次于kubernetes，是继kubernetes之后第二个加入云原生基金会的。我觉得prometheus是容器开源解决方案最佳实践，prometheus监控数据通过时序数据库存储，而时序数据库是NOSQL，能轻松解决zabbix关系型数据库面临的高并发、高存储、高扩展的三高问题。 但prometheus有两个缺点：第一个缺点，需要针对每个中间件或者监控目标都要单独安装export，有多个监控目标的话，多个监控目标对应暴露http服务端口，在维护管理等方面非常不便；第二个缺点，prometheus的监控项值只能为浮点数据类型，不能存储字符数据类型，这个限制就有点大了。为什么不能存储字符串数据类型，因为官方觉得涉及字符串类型都属于日志监控范畴。 为了解决这两个技术问题，然后就出现了我们监控方案九：TICK。 监控方案九：T是Telegraf的简称，I是influxdb、C是Chronograf、K是kapacitor。Telegraf是一个监控数据采集代理，能采集收集多个监控目标，解决了prometheus中要装多个export的问题。Influxdb作为时序数据库的老大，相比prometheus自带的TSDB存储，能存储字符数据类型。 虽然TICK解决了prometheus的两个缺点，但是带来两个新的问题。一是Chronograf监控数据展示，这方面算TICK技术栈中的弱项，相比grafana，TICK功能及图形展示效果等方面弱一些。Kapacitor报警通知这部分算TICK技术栈中的弱项，相比prometheus技术栈中的alertmanager，没有报警去重、降噪、分组等功能。 监控方案十：什么是驻云监控3.0呢？我们将 Prometheus和TICK技术栈进行了合并，利用了两套方案的优点，解决了两套方案的缺点。Telegraf + Influxdb + Prometheus + Alertmanager+ grafana解决了原生态prometheus需要安装多个export且只能存储浮点数据类型的问题，同时也解决了TICK技术栈中在监控数据图形展示、报警通知方面的缺陷。 但是驻云监控3.0架构仅解决了主机+中间件的监控问题，没办法解决云产品监控、站点监控、日志监控、代码监控方面的问题。但这些监控目标都是云监控的功能特点，所以最终我们通过api集成云监控，成为驻云3.1完整监控体系，这就是我们的监控方案十一。 第十三招 DevOps发展的四个阶段 除了监控技术外，云端当前最火的就是结合容器、集合kubernetes资源编排技术相结合的Devops相关技术了。所以，降云十八掌的第十三招就是Devops发展的四个阶段。 Devops发展经过四个阶段：人工阶段、脚本及工具阶段、平台化阶段、智能化阶段。 人工阶段，就是最为原始的劳动力阶段。都说我们IT人员是背着笔记本的农民工，我们的座右铭就是一个字：干。 到了脚本及工具阶段，我们运维通过工具、脚本尝试解决运维重复工作，这是运维自动化1.0阶段。随着业务发展，而运维自动化2.0核心就是rundeck等web图形化界面出现，研发也能通过这些web平台来进行发布代码等运维操作。 说到这里，DevOps与运维自动化有本质区别。我们知道运维和开发一直是冲突的，运维追求稳定不要变更，研发为了迭代，需要经常变更。跨部门的沟通协作，变更发布效率、质量等问题。DevOps面临及要解决的是可持续集成及可持续交付的IT体系化问题，而运维自动化仅是运维层面的自动化运维管理问题，DevOps体系其实包含运维自动化的，不是一个维度的事情。 在运维自动化2.0基础之上，出现了DevOps1.0，在DevOps1.0的核心技术是Jenkins的出现，解决了可持续集成，让代码自动化编译发布。 然后接下来平台化阶段，云本质其实是一个大的运维自动化平台，让IT运维管理一下子进入平台化及运维自动化3.0阶段。 云平台虽然能解决绝大部门企业的运维自动化诉求。但是随着业务系统变多，以及资源变多的时候，需要满足业务流程化相关联的一套独有自动化平台的时候，我们就开始需要定制自己的自动化平台。特别是未来多云平台，我们是没办法单纯用一个云厂商平台解决我们所有资源管理的问题。 容器技术的出现，让DevOps1.0走向DevOps1.0 ，最主要的是kubernetes技术引入，解决了可持续交付的问题，让业务部署发布、上线、变成秒级，以前物理机交付是天级别，现在云计算是分钟级别，然后到容器阶段变成秒级交付！ 最后一个阶段便是智能化阶段，人类的科技未来肯定是人工智能，正如电影终结者中的人机大战场景一样，随着人工智能技术成熟，机器人的时代已不再遥远。所以智能化阶段，已经脱离单纯devops体系，进入AIOPS的智能化体系。AIOPS中的AI非智能，AI体现在通过算法，通过程序来实现智能发布、扩展、故障自愈等等。 第十四招 跨云平台分布式架构 结合刚才说的容器技术，未来业务跨云平台分布式架构是最主流的形态。这便是降云十八掌的第十四招。 第一个核心技术点：我们通过容器技术DOCKER+K8S，让业务部署跨平台，不依赖云平台或者底层物理环境。 第二个核心技术点：通过DNS智能解析，我们能将用户请求分别调度转发到不同平台中。说到DNS智能解析，其实CDN的就近访问核心功能就是依靠CDN的智能解析。 在跨云平台分布式架构中，最难的技术点其实就是第三个核心技术点，就是数据同步。我们把业务部署在不同平台上，这些可能在不同地域上，我们怎么样保障不同地域连接的数据库数据实时同步，保障数据一致性？阿里云有DTS成熟的同步方案，加上专线高速通道解决数据传输速度等问题，这也是这方面较成熟的解决方案。 第十五招 企业级VPC安全架构 VPC是企业级网络安全架构最佳实践，之前跟大家介绍过混合云架构的一个案例，主要做异地跨平台数据灾备。这里另外一个核心场景就是可以把公司内部所有内部应用都放在云端。企业里面，我们不需要任何一台硬件服务器，我们只需要放几个交换机、无线路由器来供给员工日常办公网络。 但这里，我们面临最多的两个技术问题挑战，一是安全性，由于内部OA、ERP都是内部敏感业务系统，放在云端不可能通过公网暴露，所以这里解决安全问题就是通过VPN IPSEC隧道技术，通过内网传输访问保障安全性；一是访问速度问题，虽然VPN IPSEC是传输加密，但是也是基于公网，网络传输质量可能得不到。为了解决这方面问题，我们通过专线，即阿里云高速通道服务来保障及解决即可。 第十六招 云端全链路安全机制 安全的话题一直是敏感的，刚才提到VPC是企业级网络安全架构最佳实践。那在云端我们如何做好安全性？我们需要在请求链路上做全链路安全机制，保障每一个环节都是安全可靠的。这就有我们的降云十八掌第十六招——云端全链路安全机制。 一个用户请求云端业务，会经过哪些链路及流程呢？ 首先路由进入云机房，然后进入DDOS流量监测清洗集群（阿里云的DDOS集群系统，硬件方面采用华为赛门铁克专门定制的多板卡、多端口硬件，软件方面采用云盾自助研发的防御系统）。接着流入CDN节点，再流入WAF web应用防火墙，再流入飞天集群系统，即安全组规则中，再到SLB，然后流入ECS系统中，先进入iptables再到nginx，再到代码层，最后代码调用请求数据库。 所以为了保障安全性，我们需要对请求的每一个环节，每一条链接上都要做安全规则机制。 第十七招 云端运维安全十则 除了第十五招网络安全架构、第十六招全链路安全机制外，运维层面的安全防护规则是安全防御的最后一道防线。这是降云十八掌的第十七招——云端运维安全十则。 第一则：运维堡垒，即运维堡垒机，通过堡垒机我们需要做远程登录服务器的安全管理及审计。 第二则：运维用户管理，服务器不要直接开放root，不要用root运行进程。 第三则：密码安全管理，最好的密码规则就是不要有密码规则，用SSL证书验证。当前aws、阿里云对云服务器的登录验证，都是默认推荐使用证书的方式。 第四则：防火墙安全管理，防火墙的开启、安全端口管控，是运维安全中最有效的防护手段。 第五则，端口安全管理，数据库等敏感业务服务只绑定在内网端口上，切勿一股脑的全绑在0.0.0.0上，就对全网开放了。 第六则：openresty无缝兼容nginx，是云端开源waf最佳实践。 第七则：数据传输，要牢记SSL加密传输的原则。 第八则：运维安全性能调优，必要的性能调优，不仅能提升访问性能，也能冗余安全攻击。 第九则：通过冷备及热备进一步保障云端数据安全性，比如通过前面介绍的混合云架构做异地灾备。 第十则：加强安全巡检及安全培训管理，安全防护需要人人做起。 第十八招 千万级架构的演变 降龙十八掌中最后一招叫神龙摆尾，我跟降云十八掌中的最后一招也起了一个响亮的名字，叫化云为雨。 什么是一个好的架构？我觉得一个好的架构是靠演变而来，而不是单纯的靠设计。刚开始做架构设计，我们不可能全方位的考虑到架构的高性能、高扩展、高安全等各方面的因素。随着业务需求越多越多、随着业务访问压力越多越大，架构不断的演变及进化，因而造就了一个成熟稳定的大型架构。如淘宝网、如Facebook等大型网站的架构，都是从一个小型规模架构，不断演变及进化成为一个大型网站架构。 那么在云端，一个千万级架构是如何演变而来？ 架构的最原始阶段：万能的单机，即一台ECS服务器搞定一切。传统官网、论坛等应用，只需要一台ECS。对应的web服务器、数据库、静态文件资源等，都部署到这台ECS上即可。 随着访问压力增加，到达架构基础阶段：物理分离web和数据库，这是架构最为基本的分离手段，同时也是最有效的手段。部署在一台服务器上面的web应用及数据库等服务应用，会对服务器的CPU/内存/磁盘/带宽等系统资源进行争抢。显然单机已经出现性能瓶颈，这时候我们将web应用和数据库物理分离单独部署，解决对应性能问题。 随着访问压力进一步增加，到达架构动静分离阶段：静态缓存+对象缓存，我们看到前端web服务出现性能瓶颈。大量的web请求被堵塞，同时服务器的CPU、磁盘IO、带宽都有压力。这时候我们一方面将网站图片、js、css、html及应用服务相关的静态资源文件存储在oss中进行集中管理，另外一方面通过CDN将静态资源分布式缓存在各个节点实现“就近访问”。通过将动态请求、静态请求的访问分离（即“动静分离”），有效解决服务器在磁盘IO、带宽方面的访问压力。 当访问压力继续增加，到达架构分布式阶段：负载均衡，虽然“动静分离“有效分离了静态请求的压力，但是动态请求的压力已经让服务器”吃不消”。最直观的现象是，前端访问堵塞、延迟、服务器进程增多、cpu100%，并且出现常见502/503/504的错误码。显然单台web服务器已经满足不了需求，这里需要通过负载均衡技术，增加多台web服务器。因此，告别单机的时代，转变分布式架构的阶段。 当访问压力持续增加，到达架构数据缓存阶段。数据库缓存，虽然负载均衡结合多台web服务器，解决了动态请求的性能压力。但是这时候我们发现，数据库出现压力瓶颈，常见的现象就是RDS的连接数增加并且堵塞、CPU100%、IOPS飙升。这个时候我们可以通过memcache、redis等数据库缓存技术，有效减少数据库访问压力，进一步提升性能。 访问压力继续增加，到达架构扩展阶段。垂直扩展，虽然这个时候我们可以看到通过分布式文件系统OSS，已经解决了文件存储的性能问题，虽然通过CDN已经解决静态资源访问的性能问题。但是当访问压力再次增加，这个时候web服务器和数据库方面依旧是瓶颈。在此我们通过业务拆分、读写分离、分库等垂直扩展技术，进一步切分web服务器和数据库的压力，解决性能问题。 最后到达架构扩展阶段：水平扩展，当达到千万级架构以上访问量的时候，我们可以看到垂直扩展的架构也已经开始“山穷水尽”。比如，读写分离仅解决读的压力，面对高访问量，数据库在“写”的压力上面“力不从心”，出现性能瓶颈。另外，分库虽然将压力拆分到不同数据库中。但是，单表的数据量达到TB级别以上的时候，显然已经达到传统关系型数据库处理的极限。我们通过增加更多的web服务器、增加更多的SLB、采用分布式缓存、以及引入sharding 和nosql分布式数据库等水平扩展的技术，让架构能够进行水平扩展。满足千万级架构及更高的要求。 到这里，降云十八掌的全部内容已跟大家分享完，希望对大家能有帮助。 想和更多的运维开发者交流，识别下方二维码即可加入钉钉交流群！ 演讲嘉宾：乔锐杰，驻云科技运维总监，人送外号“专家”，圈内人称“乔帮主”。阿里云资深架构师/技术专家，阿里云全球MVP获得者，《「阿里云」运维架构最佳实践》作者。曾担任黑客讲师/Java高级讲师/Python讲师/运维高级讲师/阿里云讲师，从事过安全、研发、高级运维、架构师、运维总监/技术总监等相关职位。国内云端架构与运维实践开拓者，曾主导过电商、金融、政府、视频、游戏等领域千万级云端架构，在云端分布式集群架构、云端运维、云端安全等方面有着丰富的实战经验。

数据库基础知识 为什么要使用数据库 什么是SQL？ 什么是MySQL? 数据库三大范式是什么 mysql有关权限的表都有哪几个 MySQL的binlog有有几种录入格式？分别有什么区别？ 数据类型 mysql有哪些数据类型 引擎 MySQL存储引擎MyISAM与InnoDB区别 MyISAM索引与InnoDB索引的区别？ InnoDB引擎的4大特性 存储引擎选择 数据库基础知识 为什么要使用数据库 （1）数据保存在内存 优点： 存取速度快 缺点： 数据不能永久保存 （2）数据保存在文件 优点： 数据永久保存 缺点： 1）速度比内存操作慢，频繁的IO操作。 2）查询数据不方便 （3）数据保存在数据库 1）数据永久保存 2）使用SQL语句，查询方便效率高。 3）管理数据方便 什么是SQL？ 结构化查询语言(Structured Query Language)简称SQL，是一种数据库查询语言。 作用：用于存取数据、查询、更新和管理关系数据库系统。 什么是MySQL? MySQL是一个关系型数据库管理系统，由瑞典MySQL AB 公司开发，属于 Oracle 旗下产品。MySQL 是最流行的关系型数据库管理系统之一，在 WEB 应用方面，MySQL是最好的 RDBMS (Relational Database Management System，关系数据库管理系统) 应用软件之一。在Java企业级开发中非常常用，因为 MySQL 是开源免费的，并且方便扩展。 数据库三大范式是什么 第一范式：每个列都不可以再拆分。 第二范式：在第一范式的基础上，非主键列完全依赖于主键，而不能是依赖于主键的一部分。 第三范式：在第二范式的基础上，非主键列只依赖于主键，不依赖于其他非主键。 在设计数据库结构的时候，要尽量遵守三范式，如果不遵守，必须有足够的理由。比如性能。事实上我们经常会为了性能而妥协数据库的设计。 MySQL有关权限的表都有哪几个 MySQL服务器通过权限表来控制用户对数据库的访问，权限表存放在mysql数据库里，由mysql_install_db脚本初始化。这些权限表分别user，db，table_priv，columns_priv和host。下面分别介绍一下这些表的结构和内容：欢迎关注公种浩：程序员追风，领取一线大厂Java面试题总结+各知识点学习思维导图+一份300页pdf文档的Java核心知识点总结！ user权限表：记录允许连接到服务器的用户帐号信息，里面的权限是全局级的。 db权限表：记录各个帐号在各个数据库上的操作权限。 table_priv权限表：记录数据表级的操作权限。 columns_priv权限表：记录数据列级的操作权限。 host权限表：配合db权限表对给定主机上数据库级操作权限作更细致的控制。这个权限表不受GRANT和REVOKE语句的影响。 MySQL的binlog有有几种录入格式？分别有什么区别？ 有三种格式，statement，row和mixed。 statement模式下，每一条会修改数据的sql都会记录在binlog中。不需要记录每一行的变化，减少了binlog日志量，节约了IO，提高性能。由于sql的执行是有上下文的，因此在保存的时候需要保存相关的信息，同时还有一些使用了函数之类的语句无法被记录复制。 row级别下，不记录sql语句上下文相关信息，仅保存哪条记录被修改。记录单元为每一行的改动，基本是可以全部记下来但是由于很多操作，会导致大量行的改动(比如alter table)，因此这种模式的文件保存的信息太多，日志量太大。 mixed，一种折中的方案，普通操作使用statement记录，当无法使用statement的时候使用row。 此外，新版的MySQL中对row级别也做了一些优化，当表结构发生变化的时候，会记录语句而不是逐行记录。 数据类型 mysql有哪些数据类型 1、整数类型，包括TINYINT、SMALLINT、MEDIUMINT、INT、BIGINT，分别表示1字节、2字节、3字节、4字节、8字节整数。任何整数类型都可以加上UNSIGNED属性，表示数据是无符号的，即非负整数。 长度：整数类型可以被指定长度，例如：INT(11)表示长度为11的INT类型。长度在大多数场景是没有意义的，它不会限制值的合法范围，只会影响显示字符的个数，而且需要和UNSIGNED ZEROFILL属性配合使用才有意义。 例子，假定类型设定为INT(5)，属性为UNSIGNED ZEROFILL，如果用户插入的数据为12的话，那么数据库实际存储数据为00012。 2、实数类型，包括FLOAT、DOUBLE、DECIMAL。 DECIMAL可以用于存储比BIGINT还大的整型，能存储精确的小数。 而FLOAT和DOUBLE是有取值范围的，并支持使用标准的浮点进行近似计算。 计算时FLOAT和DOUBLE相比DECIMAL效率更高一些，DECIMAL你可以理解成是用字符串进行处理。 3、字符串类型，包括VARCHAR、CHAR、TEXT、BLOB VARCHAR用于存储可变长字符串，它比定长类型更节省空间。 VARCHAR使用额外1或2个字节存储字符串长度。列长度小于255字节时，使用1字节表示，否则使用2字节表示。 VARCHAR存储的内容超出设置的长度时，内容会被截断。 CHAR是定长的，根据定义的字符串长度分配足够的空间。 CHAR会根据需要使用空格进行填充方便比较。 CHAR适合存储很短的字符串，或者所有值都接近同一个长度。 CHAR存储的内容超出设置的长度时，内容同样会被截断。 使用策略： 对于经常变更的数据来说，CHAR比VARCHAR更好，因为CHAR不容易产生碎片。 对于非常短的列，CHAR比VARCHAR在存储空间上更有效率。 使用时要注意只分配需要的空间，更长的列排序时会消耗更多内存。 尽量避免使用TEXT/BLOB类型，查询时会使用临时表，导致严重的性能开销。 4、枚举类型（ENUM），把不重复的数据存储为一个预定义的集合。 有时可以使用ENUM代替常用的字符串类型。 ENUM存储非常紧凑，会把列表值压缩到一个或两个字节。 ENUM在内部存储时，其实存的是整数。 尽量避免使用数字作为ENUM枚举的常量，因为容易混乱。 排序是按照内部存储的整数 5、日期和时间类型，尽量使用timestamp，空间效率高于datetime， 用整数保存时间戳通常不方便处理。 如果需要存储微妙，可以使用bigint存储。 看到这里，这道真题是不是就比较容易回答了。 引擎 1、MySQL存储引擎MyISAM与InnoDB区别 存储引擎Storage engine：MySQL中的数据、索引以及其他对象是如何存储的，是一套文件系统的实现。 常用的存储引擎有以下： Innodb引擎：Innodb引擎提供了对数据库ACID事务的支持。并且还提供了行级锁和外键的约束。它的设计的目标就是处理大数据容量的数据库系统。欢迎关注公种浩：程序员追风，领取一线大厂Java面试题总结+各知识点学习思维导图+一份300页pdf文档的Java核心知识点总结！ MyIASM引擎(原本Mysql的默认引擎)：不提供事务的支持，也不支持行级锁和外键。 MEMORY引擎：所有的数据都在内存中，数据的处理速度快，但是安全性不高。 2、MyISAM与InnoDB区别 3、MyISAM索引与InnoDB索引的区别？ InnoDB索引是聚簇索引，MyISAM索引是非聚簇索引。 InnoDB的主键索引的叶子节点存储着行数据，因此主键索引非常高效。 MyISAM索引的叶子节点存储的是行数据地址，需要再寻址一次才能得到数据。 InnoDB非主键索引的叶子节点存储的是主键和其他带索引的列数据，因此查询时做到覆盖索引会非常高效。 4、InnoDB引擎的4大特性 插入缓冲（insert buffer) 二次写(double write) 自适应哈希索引(ahi) 预读(read ahead) 5、存储引擎选择 如果没有特别的需求，使用默认的Innodb即可。 MyISAM：以读写插入为主的应用程序，比如博客系统、新闻门户网站。 Innodb：更新（删除）操作频率也高，或者要保证数据的完整性；并发量高，支持事务和外键。比如OA自动化办公系统。 最后欢迎大家一起交流，喜欢文章记得关注我点个赞哟，ganxe感谢支持

引用：http://baike.baidu.com/view/1413359.htm 新浪的SAE 阿里ace 百度 bae PaaS是Platform-as-a-Service的缩写，意思是平台即服务。 把服务器平台作为一种服务提供的商业模式。通过网络进行程序提供的服务称之为SaaS(Software as a Service)，而云计算时代相应的服务器平台或者开发环境作为服务进行提供就成为了PaaS(Platform as a Service)。   目录 定义 特点 APaaS和IPaaS 公有云PaaS和企业级PaaS 水处理化学品 展开   编辑本段定义 　　PaaS，全称:(Platform as a service) ，中文：平台即服务。   　　实例：CloudCC PaaS的优势(1张)   　　所谓PaaS实际上是指将软件研发的平台（计世资讯定义为业务基础平台）作为一种服务，以SaaS的模式提交给用户。因此，PaaS也是SaaS模式的一种应用。但是，PaaS的出现可以加快SaaS的发展，尤其是加快SaaS应用的开发速度。在2007年国内外SaaS厂商先后推出自己的PAAS平台。   　　PAAS之所以能够推进SaaS的发展，主要在于它能够提供企业进行定制化研发的中间件平台，同时涵盖数据库和应用服务器等。PAAS可以提高在Web平台上利用的资源数量。例如，可通过远程Web服务使用数据即服务（Data-as-a-Service：数据即服务），还可以使用可视化的API，甚至像800app的PAAS平台还允许你混合并匹配适合你应用的其他平台。用户或者厂商基于PaaS平台可以快速开发自己所需要的应用和产品。同时，PaaS平台开发的应用能更好地搭建基于SOA架构的企业应用。   　　此外，PAAS对于SaaS运营商来说，可以帮助他进行产品多元化和产品定制化。例如 Salesforce的PAAS平台让更多的ISV成为其平台的客户，从而开发出基于他们平台的多种SaaS应用，使其成为多元化软件服务供货商（Multi Application Vendor），而不再只是一家CRM随选服务提供商。而国内的SaaS厂商800app通过PAAS平台，改变了仅是CRM供应商的市场定位，实现了 BTO(Built to order:按订单生产)，和在线交付流程。使用800app的PAAS开发平台，用户不再需要任何编程即可开发包括CRM、OA、HR、SCM、进销存管理等任何企业管理软件，而且不需要使用其他软件开发工具并立即在线运行。   　　面向个人的EC站点(electronic commerce site)的巨头公司 Amazon，把最初为了自己公司的运营用的构筑起来的系统平台，进行出租，用户可以自由选择操作系统和中间软件，以这样的方式提供硬件以及软件平台作为服务，最初被海外以一些冒险事业的企业所使用。从2006年开始 [Amazon EC] [Amazon S3]开始作为服务推向市场。   　　还有现代软件业霸主同时又是次时代计算的先驱的Google,大家都知道在世界上构筑以及运行了非常多的数据中心。以搜索引擎以及新的广告模式而闻名。他们使用便宜的计算机和强有力的中间件，以及自己的技术装备出了世界上最强大的数据中心，以及超高性能的并行计算群。 2008年4月发表的PaaS服务[Google App Engine]和Amazon 的 EC2,S3,SimpleDB等服务拥有相似的功能。这些稳定的平台上同样搜索引擎，GMail等服务也在运行。同样以ASP~SaaS成功的Salesforce，2007年开始用于提供SaaS的系统基盘对外公开，用Force这个名称开始进入PaaS业务。他所提供的PaaS服务里采用Java类似的语言Apex以及Eclipse开发平台，整合的开发环境也作为服务进行提供(Development as a Service)。Google/Amazon/Salesforce这三个软件巨头非常的重视PaaS这种新的商业模式，Amazon的PaaS服务为了用户可以自由的组合服务提供了更多的自由度，Google的话提供了更多的服务使用户能够方便的使用，去掉了一些繁琐的作业。Google/Salesforce的PaaS不仅是基础硬件的提供开发环境的同样被提供属于真正的平台作为一种服务(PaaS)   编辑本段特点 　　PaaS能将现有各种业务能力进行整合，具体可以归类为应用服务器、业务能力接入、业务引擎、业务开放平台，向下根据业务能力需要测算基础服务能力，通过IaaS提供的API调用硬件资源，向上提供业务调度中心服务，实时监控平台的各种资源，并将这些资源通过API开放给SaaS用户。PaaS主要具备以下三个特点:   　　(1)平台即服务：PaaS所提供的服务与其他的服务最根本的区别是PaaS提供的是一个基础平台，而不是某种应用。在传统的观念中，平台是向外提供服务的基础。一般来说，平台作为应用系统部署的基础，是由应用服务提供商搭建和维护的，而PaaS颠覆了这种概念，由专门的平台服务提供商搭建和运营该基础平台，并将该平台以服务的方式提供给应用系统运营商；   　　(2)平台及服务:PaaS运营商所需提供的服务，不仅仅是单纯的基础平台，而且包括针对该平台的技术支持服务，甚至针对该平台而进行的应用系统开发、优化等服务。PaaS的运营商最了解他们所运营的基础平台，所以由PaaS运营商所提出的对应用系统优化和改进的建议也非常重要。而在新应用系统的开发过程中，PaaS运营商的技术咨询和支持团队的介入，也是保证应用系统在以后的运营中得以长期、稳定运行的重要因素;   　　(3)平台级服务:PaaS运营商对外提供的服务不同于其他的服务，这种服务的背后是强大而稳定的基础运营平台，以及专业的技术支持队伍。这种“平台级”服务能够保证支撑SaaS或其他软件服务提供商各种应用系统长时间、稳定的运行。PaaS的实质是将互联网的资源服务化为可编程接口，为第三方开发者提供有商业价值的资源和服务平台。有了PaaS平台的支撑，云计算的开发者就获得了大量的可编程元素，这些可编程元素有具体的业务逻辑，这就为开发带来了极大的方便，不但提高了开发效率，还节约了开发成本。有了PaaS平台的支持，WEB应用的开发变得更加敏捷，能够快速响应用户需求的开发能力，也为最终用户带来了实实在在的利益。   编辑本段APaaS和IPaaS 　　简单的说，PaaS平台就是指云环境中的应用基础设施服务，也可以说是中间件即服务。PaaS平台在云架构中位于中间层，其上层是SaaS，其下层是IaaS。在传统On-Premise部署方式下，应用基础设施即中间件的种类非常多， 有应用服务器，数据库，ESBs, BPM, Portal, 消息中间件，远程对象调用中间件等等。对于PaaS平台，Gartner把它们分为两类，一类是应用部署和运行平台APaaS（application platform as a service)，另一类是集成平台IPaaS（integration as a service）。 人们经常说的PaaS平台基本上是指APaaS，如Force和Google App Engine。   编辑本段公有云PaaS和企业级PaaS 　　云计算起源于大型互联网企业。对于互联网企业，成本压力和指数级的业务增长压力使他们关注于物理资源的利用率和应用的可扩展性。在应用服务器这层，通过Cluster Session来实现水平扩展；在数据存储这层，采用基于BASE模型的NOSQL数据存储来实现扩展。目前互联网企业主导面向公众服务的公有云PaaS平台，如Google App Engine和Amazon Beanstalk。对于公有云PaaS平台，PaaS就是云环境下的应用部署平台。   　　（1）基于商业软件的部署方式：Application - Framework/Libs - Websphere/Weblogic + RMBMS   　　（2）基于开源软件的部署方式：Application - Frameworks/Libs - Tomcat/JBoss + RDBMS   　　（3）云环境下的部署方式：Application - Frameworks/Libs - PaaS(Goole App Engine, Amazon)   　　这种情况下，PaaS实质上就是一个预先装好的Web Container和一组公共服务，如数据存储服务(不一定是关系型数据库)、消息队列、集中式session及cache等等。对于个人用户或者简单应用来说，公有云PaaS平台使得开发人员仅关注应用逻辑开发本身，不用把精力花费在基础实施和应用的扩展和维护上。   　　所谓企业级PaaS平台，主要包含两类，一是大型企业内部的私有云PaaS平台，另一类是面向ISV厂商的PaaS平台。然而对于企业级PaaS平台，PaaS不仅仅是云环境下的应用部署平台。 抛开安全问题不讲，私有云PaaS平台和公有云PaaS有如下核心区别：   　　（1）复杂的多租户模型：对于公有云PaaS平台，其租户模型是 （用户-> 应用 -> 应用实例），一个用户可以部署多个应用，每个应用可以有多个运行时实例，应用实例共享资源池。对于一个大型企业，一个大部门可能是一个租户，大部门下面的子部门也是一个租户；或者一个SaaS应用系统的一个实例就是一个租户。对于租户的资源使用，大部门租户是共享资源池里面的资源，也可能某些关键租户需要独占一些资源以保证安全。   　　（2）已有应用的兼容：企业的历史应用都是基于关系型数据库的，某些PaaS平台不支持关系型数据存储，即使是简单的已有应用都无法迁移到PaaS平台上。   　　（3）复合应用的构建: 企业On-Premise应用在很长一段时间内都是要存在的，私有云PaaS平台要成为On-Premise和公有云之间的桥梁。私有云PaaS平台除了是应用部署平台外，还需要提供集成和方便构建复合应用的能力，就是Gartner所提的iPaaS能力。 企业级PaaS平台不仅仅是应用部署平台，而且是复杂多租户环境和复杂应用环境下的共享基础设施平台，是On-Premise部署通往公有云部署的必经之路。   　　PaaS体验实例：CloudCC PaaS平台   　　PaaS的理解有时候是基于IT技术层面的，因此给普通使用者一个直观的体验是理解PaaS的最好方式，通过沟通，我们获取了CloudCC PaaS平台的体验支持，只需要访问CloudCC云计算中国网，就能获取体验路径。

Web端开发框架如何选 目前，大部分的企业信息集成系统都在web端运行，而搭建框架的选择对一个企业的发展至关重要，不过其最终目的都是要符合企业发展逻辑，助力企业战略的实施。 而在框架的选择上就是一个仁者见仁的事情了，就从底层框架来说，web层的就非常多，而且各有特色，比如：Struts、WebWork、Spring MVC、Tapestry、JSF、WebPage3.0……等等。 那么为什么要使用框架呢？ 使用框架的必然性 框架，即framework，说白了，其实就是一些应用的半成品。通常情况下，为了方便应用，会把不同应用程序中一些共性的东西剥离出来，做成一个半成品程序，这样的半成品就是程序框架。当然，这些东西有免费的，也有付费的，免费的在功能上和后期维护上需要更多的心思，而付费的通常由一些开发企业做优化，开发一些标准功能，再加上一定的拓展，维护成本上会更低一些。 目前，软件系统的发展已经相当复杂了，特别是服务器端软件，涉及到的知识，内容，问题太多。在某些方面使用别人成熟的框架，就相当于让别人帮你完成一些基础工作，而你只需要集中精力完成系统的业务逻辑设计。这样每次开发就不用白手起家，而是可以在这个基础上快速搭建。 这样一方面可以减少重复开发工作量、缩短开发时间、降低开发成本，另一方面也可以使程序设计更合理、运行更稳定，减少了人员流动所带来的困扰。基于这些原因，基本上现在在开发中，都会选用某些合适的开发框架，来帮助建立快速高效的开发应用系统。 那么有了这些必然性，选择就很重要了，在web层的开发框架中，有一些基础思想很值得注意。 1.数据展示 Web层需要从逻辑层获取需要展示的数据，然后以合理的方式在页面进行展示，要做到分类明确，抓取精准，使用方便，界面简洁。 2.人机交互 人机交互，其实是说的软件智能化。比如用户要在界面上输入数据，并在界面上进行点击操作，那么就可以触发事件，建立标准的事件驱动模型，然后自动与后台机型数据交换处理，从而完成新界面的建立。 3.收集数据，调用逻辑层接口 这个过程的触发和用户的操作请求是同步的。通常web层收到用户的请求，便需要相应的逻辑层接口来处理，因为本身web层是不会进行任何逻辑处理的，这其实也是前后端的差异。而调用逻辑层接口，需要传递参数，这时需要收集用户在界面上输入的数据，然后进行组织，组织成为逻辑层接口需要的数据封装形式，这种形式有很多，常用的是ValueObject。 4.根据逻辑层的数据来重新展示页面 逻辑层处理完了，但是前端显示依然没有变化，这时候需要将数据或信息重新返回到展示界面上，界面再将数值分配到具体的位置，新的页面便展示出来了。 其实通过以上我们也可以看出来，web层的开发工作重要集中在展示上，也就是图形用户界面，这是用户最直观的感受应用程序的窗口，通常也是用户要求比较多的地方之一，其表现形式相对丰富。 Web层开发步骤 其实，任何项目从零开始，开发步骤都大同小异，只是有条件的企业会采用同步开发的模式，以节省时间，这里以基础模式为例，简述一下。 1. 确定展现内容，写页面Html 2. 每个数据的具体表现形式，如：有的需要表现成为下拉列表，有的需要表现成为单选按钮等。 3.界面表现形式的逻辑布局，所谓逻辑布局是指某些数据的表现形式应该放在前面，某些应该放在后面；某些放在上面，某些放在下面。如：某个请假申请 的业务，有请假开始时间和结束时间，很明显开始时间的表现就应该排在结束时间的前面。而美工是负责最后页面的美观，一般美工不能动界面的逻辑布局。 4.完成前面3步，页面的表现形式的大致模样就有了，下面需要来做功能性的开发。第一个就是这些表现形式的值的来源，如：下拉列表显示的值从什么地方来。值的来源方式很多，有数据库中来、固定值、某断程序运行的中间结果、前面页面传递过来等等，当然典型的还是来自数据库。 好了，确定了值的来源，开发人员就要写代码来获取这些值，然后把这些值赋值到对应的表现形式里面。 5.还有一些比较特殊，也就是真实操作的是一类值，但是在界面上显示的是另一类值，比如：数据库中有用户编号，到了界面上就得显示用户姓名，但是所 有的操作都是要操作用户编号的。我们把这种情况分做：真实值和表现值，他们有一定的内在联系。这些都是要开发人员去转化和维护的。 6.接下来就应该开发功能性的事件响应了。用户点击了某个按钮或者触发了某个事件，首先是客户端：数据检测、客户端事件处理;然后提交到服务端，服务端要获取到客户端提交的数据，然后调用相应的逻辑层接口来响应。当然如何写逻辑层的实现这里就不去谈论了。 7.逻辑层执行完过后，返回数据和信息到Web层，开发人员还需要写代码去处理，选择哪个页面来显示，如何显示这些数据和信息等。 8.在整个交互的过程中，还必须考虑到如何控制权限，如：某些数据不能显示，某些数据不能编辑等等;同样还需要考虑到消息的配置和国际化等等。这些功能起源于逻辑层，但是实际的控制要到Web层，这些都需要开发人员来控制。 9.完成了上面的开发步骤，页面基本的功能开发就告一段落，接下来开发人员需要考虑页面美观的问题了。大家可能会说：“不是有美工吗，还需要开发人 员干什么?”。事实上美工多半只能出一个静态页面的美化模版，美工对于一推Java代码和Html的混杂物，多半是没有办法的，更不要说还有一些内容是动态生成的，美工就更不可能搞定了。还是得开发人员上阵，按照美工给的模版，开始添加Css：class、id、style…… 10：完成上面的开发，基本页面的开发工作就完成了，最后的一个步骤就是把各个页面有机的组织起来，开发应用程序的整体应用导航框架，通常就是菜单，然后把各个功能页面跟菜单结合起来，形成一个完整的应用。 在这里我们省略了开发期反复的调试过程，仅总结开发的步骤。 选择Web开发框架的目的 首先，没有框架，我们需要做的工作是什么，了解了这些，我们才能更好的明白框架的价值。 框架，通俗地讲，就是一个半成品，也就是组成一个机器的零件。目前我们使用的框架无论是基础的底层框架，还是融合类型的付费框架，莫不如此。 而框架的选择，要看项目的实际需求，底层框架适用于时间充裕的项目搭建，融合框架（快速开发框架）适用于短期项目，从成本上来说，通用型融合框架可以减少开发的工作量，提高工作效率，因为其本身已经融合了多种常用功能，ERP、OA、CRM、BI、甚至移动APP等，对企业来讲，可操作性更强。 选择Web开发框架的标准 标准不是一成不变的，这里也只是经验之谈，而且主要出发点在融合框架的业务功能方面，所以仅作参考之用。 1.选择能够对我们的开发过程提供更多、更好帮助的Web开发框架，功能性，稳定性要强。 2.Web开发框架的学习一定要简单，上手一定要快，毕竟，没有人愿意在复杂错乱的框架结构中摸索，一个成熟的融合框架，如果需要半个月甚至一个月的学习周期，那这个框架确实有需要商榷的地方。 3.良好的技术支持。框架无论好坏，技术支持一定要做好，因为等你使用起来就明白，无论多好的框架，在实际的应用过程中，都会或多或少的出现问题，如果不能及时的解决，会对整个项目开发带来影响。 此外，一定要考虑综合成本，其实这是目前应用开源软件最大的问题，碰到问题除了死肯文档就是查阅源代码，或者是网上搜寻解决的办法，通常一个问题就会导致1-2天的开发停顿，严重的甚至需要一个星期或者更长，一个项目有上这么几次，项目整体的开发成本嗖嗖的就上去了。 4.Web开发框架结合其他技术的能力一定要强，比如在逻辑层使用Spring或者Ejb3，同时框架整体也要很容易的与它们进行结合。 5.强大的拓展功能。就像刚才所说的，再好的框架都不可能做到面面俱到，况且每个企业的实际情况都有所不同，因此这就要求框架的拓展功能足够强大，以满足新业务的需求。但是，此处要注意一点，扩展一点要简单，如果因为扩展功能而使框架整体功能受限，硬塞上去也是不合适的。 6.Web开发框架最好能提供可视化的开发和配置，可视化开发对开发效率的提高，已经得到业界公认，况且这一功能目前来说已经相对成熟，不多赘述。 7.Web开发框架的设计结构一定要合理，应用程序会基于这个框架，框架设计的不合理会大大影响到整个应用的可扩展性。 8.Web开发框架一定要能很好的结合目前公司的积累，可以有良好的项目对接。通常情况下，公司在多年的开发中已有了很多积累，不能因为使用Web开发框架就不能再使用了，那未免有些得不偿失。 9.不要把框架想的神了。可以肯定的是，目前市面上的所有框架都不可能做到十全十美，也不可能适用所有应用场景，所以在选型前一定要了解它的适用范围，判断是否合适。 这里给大家推荐一款我公司使用的敏捷开发框架learun，谨作选型参考，页面地址：免费体验 云服务器ECS地址：阿里云·云小站

Web端开发框架如何选 目前，大部分的企业信息集成系统都在web端运行，而搭建框架的选择对一个企业的发展至关重要，不过其最终目的都是要符合企业发展逻辑，助力企业战略的实施。 而在框架的选择上就是一个仁者见仁的事情了，就从底层框架来说，web层的就非常多，而且各有特色，比如：Struts、WebWork、Spring MVC、Tapestry、JSF、WebPage3.0……等等。 那么为什么要使用框架呢？ 使用框架的必然性 框架，即framework，说白了，其实就是一些应用的半成品。通常情况下，为了方便应用，会把不同应用程序中一些共性的东西剥离出来，做成一个半成品程序，这样的半成品就是程序框架。当然，这些东西有免费的，也有付费的，免费的在功能上和后期维护上需要更多的心思，而付费的通常由一些开发企业做优化，开发一些标准功能，再加上一定的拓展，维护成本上会更低一些。 目前，软件系统的发展已经相当复杂了，特别是服务器端软件，涉及到的知识，内容，问题太多。在某些方面使用别人成熟的框架，就相当于让别人帮你完成一些基础工作，而你只需要集中精力完成系统的业务逻辑设计。这样每次开发就不用白手起家，而是可以在这个基础上快速搭建。 这样一方面可以减少重复开发工作量、缩短开发时间、降低开发成本，另一方面也可以使程序设计更合理、运行更稳定，减少了人员流动所带来的困扰。基于这些原因，基本上现在在开发中，都会选用某些合适的开发框架，来帮助建立快速高效的开发应用系统。 那么有了这些必然性，选择就很重要了，在web层的开发框架中，有一些基础思想很值得注意。 1.数据展示 Web层需要从逻辑层获取需要展示的数据，然后以合理的方式在页面进行展示，要做到分类明确，抓取精准，使用方便，界面简洁。 2.人机交互 人机交互，其实是说的软件智能化。比如用户要在界面上输入数据，并在界面上进行点击操作，那么就可以触发事件，建立标准的事件驱动模型，然后自动与后台机型数据交换处理，从而完成新界面的建立。 3.收集数据，调用逻辑层接口 这个过程的触发和用户的操作请求是同步的。通常web层收到用户的请求，便需要相应的逻辑层接口来处理，因为本身web层是不会进行任何逻辑处理的，这其实也是前后端的差异。而调用逻辑层接口，需要传递参数，这时需要收集用户在界面上输入的数据，然后进行组织，组织成为逻辑层接口需要的数据封装形式，这种形式有很多，常用的是ValueObject。 4.根据逻辑层的数据来重新展示页面 逻辑层处理完了，但是前端显示依然没有变化，这时候需要将数据或信息重新返回到展示界面上，界面再将数值分配到具体的位置，新的页面便展示出来了。 其实通过以上我们也可以看出来，web层的开发工作重要集中在展示上，也就是图形用户界面，这是用户最直观的感受应用程序的窗口，通常也是用户要求比较多的地方之一，其表现形式相对丰富。 Web层开发步骤 其实，任何项目从零开始，开发步骤都大同小异，只是有条件的企业会采用同步开发的模式，以节省时间，这里以基础模式为例，简述一下。 1. 确定展现内容，写页面Html 2. 每个数据的具体表现形式，如：有的需要表现成为下拉列表，有的需要表现成为单选按钮等。 3.界面表现形式的逻辑布局，所谓逻辑布局是指某些数据的表现形式应该放在前面，某些应该放在后面；某些放在上面，某些放在下面。如：某个请假申请 的业务，有请假开始时间和结束时间，很明显开始时间的表现就应该排在结束时间的前面。而美工是负责最后页面的美观，一般美工不能动界面的逻辑布局。 4.完成前面3步，页面的表现形式的大致模样就有了，下面需要来做功能性的开发。第一个就是这些表现形式的值的来源，如：下拉列表显示的值从什么地方来。值的来源方式很多，有数据库中来、固定值、某断程序运行的中间结果、前面页面传递过来等等，当然典型的还是来自数据库。 好了，确定了值的来源，开发人员就要写代码来获取这些值，然后把这些值赋值到对应的表现形式里面。 5.还有一些比较特殊，也就是真实操作的是一类值，但是在界面上显示的是另一类值，比如：数据库中有用户编号，到了界面上就得显示用户姓名，但是所 有的操作都是要操作用户编号的。我们把这种情况分做：真实值和表现值，他们有一定的内在联系。这些都是要开发人员去转化和维护的。 6.接下来就应该开发功能性的事件响应了。用户点击了某个按钮或者触发了某个事件，首先是客户端：数据检测、客户端事件处理;然后提交到服务端，服务端要获取到客户端提交的数据，然后调用相应的逻辑层接口来响应。当然如何写逻辑层的实现这里就不去谈论了。 7.逻辑层执行完过后，返回数据和信息到Web层，开发人员还需要写代码去处理，选择哪个页面来显示，如何显示这些数据和信息等。 8.在整个交互的过程中，还必须考虑到如何控制权限，如：某些数据不能显示，某些数据不能编辑等等;同样还需要考虑到消息的配置和国际化等等。这些功能起源于逻辑层，但是实际的控制要到Web层，这些都需要开发人员来控制。 9.完成了上面的开发步骤，页面基本的功能开发就告一段落，接下来开发人员需要考虑页面美观的问题了。大家可能会说：“不是有美工吗，还需要开发人 员干什么?”。事实上美工多半只能出一个静态页面的美化模版，美工对于一推Java代码和Html的混杂物，多半是没有办法的，更不要说还有一些内容是动态生成的，美工就更不可能搞定了。还是得开发人员上阵，按照美工给的模版，开始添加Css：class、id、style…… 10：完成上面的开发，基本页面的开发工作就完成了，最后的一个步骤就是把各个页面有机的组织起来，开发应用程序的整体应用导航框架，通常就是菜单，然后把各个功能页面跟菜单结合起来，形成一个完整的应用。 在这里我们省略了开发期反复的调试过程，仅总结开发的步骤。 选择Web开发框架的目的 首先，没有框架，我们需要做的工作是什么，了解了这些，我们才能更好的明白框架的价值。 框架，通俗地讲，就是一个半成品，也就是组成一个机器的零件。目前我们使用的框架无论是基础的底层框架，还是融合类型的付费框架，莫不如此。 而框架的选择，要看项目的实际需求，底层框架适用于时间充裕的项目搭建，融合框架（快速开发框架）适用于短期项目，从成本上来说，通用型融合框架可以减少开发的工作量，提高工作效率，因为其本身已经融合了多种常用功能，ERP、OA、CRM、BI、甚至移动APP等，对企业来讲，可操作性更强。 选择Web开发框架的标准 标准不是一成不变的，这里也只是经验之谈，而且主要出发点在融合框架的业务功能方面，所以仅作参考之用。 1.选择能够对我们的开发过程提供更多、更好帮助的Web开发框架，功能性，稳定性要强。 2.Web开发框架的学习一定要简单，上手一定要快，毕竟，没有人愿意在复杂错乱的框架结构中摸索，一个成熟的融合框架，如果需要半个月甚至一个月的学习周期，那这个框架确实有需要商榷的地方。 3.良好的技术支持。框架无论好坏，技术支持一定要做好，因为等你使用起来就明白，无论多好的框架，在实际的应用过程中，都会或多或少的出现问题，如果不能及时的解决，会对整个项目开发带来影响。 此外，一定要考虑综合成本，其实这是目前应用开源软件最大的问题，碰到问题除了死肯文档就是查阅源代码，或者是网上搜寻解决的办法，通常一个问题就会导致1-2天的开发停顿，严重的甚至需要一个星期或者更长，一个项目有上这么几次，项目整体的开发成本嗖嗖的就上去了。 4.Web开发框架结合其他技术的能力一定要强，比如在逻辑层使用Spring或者Ejb3，同时框架整体也要很容易的与它们进行结合。 5.强大的拓展功能。就像刚才所说的，再好的框架都不可能做到面面俱到，况且每个企业的实际情况都有所不同，因此这就要求框架的拓展功能足够强大，以满足新业务的需求。但是，此处要注意一点，扩展一点要简单，如果因为扩展功能而使框架整体功能受限，硬塞上去也是不合适的。 6.Web开发框架最好能提供可视化的开发和配置，可视化开发对开发效率的提高，已经得到业界公认，况且这一功能目前来说已经相对成熟，不多赘述。 7.Web开发框架的设计结构一定要合理，应用程序会基于这个框架，框架设计的不合理会大大影响到整个应用的可扩展性。 8.Web开发框架一定要能很好的结合目前公司的积累，可以有良好的项目对接。通常情况下，公司在多年的开发中已有了很多积累，不能因为使用Web开发框架就不能再使用了，那未免有些得不偿失。 9.不要把框架想的神了。可以肯定的是，目前市面上的所有框架都不可能做到十全十美，也不可能适用所有应用场景，所以在选型前一定要了解它的适用范围，判断是否合适。 这里给大家推荐一款我公司使用的敏捷开发框架learun，谨作选型参考，页面地址：免费体验 云服务器ECS地址：阿里云·云小站

前言 WordPress 可能是很多学习搭建云计算网站的第一课，写了篇 Hello World 就匆匆结束了对 WordPress 的体验。在全球前 1,000 万的网站中，三分之一都使用了 WordPress，像国外的白宫官网、纽约邮报、微软新闻中心、国内的爱范儿等等。因此开源社区的 WordPress 有着大量的开发者贡献代码和思路，帮助我们构建一个强大而成熟的网站。 我们要实现一个架构其实最重要的是三个目标，快、稳和省。 前端访问要快，后端运行要稳，但是实现前两者不能无节制的上升成本，我们要节省成本让利益最大化。。 拆解 那我们把 WordPress 简单拆解一下：WordPress 由 PHP、HTML、CSS、JS和SQL组成。 它的运行非常简单：WebServer —— PHP —— MySQL 因此可以很简单的运行在一台服务器上。 在前期运行它当然没有问题，但是当访问量、文章数上来之后便会力不从心了。 表现就是前后台打开慢，或者是用户频繁按F5就可以让网站出现500报错，因此我们就需要进行架构的优化。同样的，我们自行开发的系统可能也是前期小规模的通过单台服务器即可，但是通过运营人员一次次的努力宣传后，用户量一上来就不行了。 这里有一个很大的误区就是无限的堆叠单台服务器的配置，这在早期物理服务器托管时代比较流行，我买的服务器是双路CPU的，现在只用一颗CPU，后面性能不够了再新增CPU，然后再新增内存条和硬盘。 这样做先不谈架构，在运维上就会变成一场灾难。随着用户量的上升，服务器将越来越不能接受升级、重启等操作带来的业务中断，因为单一系统部署软件复杂，万一一个软件的升级带来的不兼容可能就导致业务崩溃，运维人员维护软件如履薄冰。 单机优化 首先我们需要将单台服务器的性能最大化再考虑后面的架构优化，这是一个环境上线的预先准备工作。 实例配置 操作系统的选择上，整体测试下来不同的系统在云服务器ECS上的表现不一样，我自己的测试是 AliyunLinux 2 和 RHEL/CentOS 是阿里云调教的最好的，可能是阿里用RHEL生态原因，在多核心上BenchMark更好看，同时 AliyunLinux 2 专门为云服务器场景优化，性能可以提升15%左右。 然后在实例类型的选择上，其实 WordPress 并不是很占用CPU（优化后），可以选择入门型这种CPU共享的实例，如t6 t5，有效降低成本。 我们以 WordPress 为例，它是一款 PHP 应用 ，PHP是一个I/O密集型应用，在服务器的选择上保障必要的CPU性能的同时，我们尽可能选择 ESSD云盘，它的时延和每G IOPS 都比SSD云盘和高效云盘表现更好。 在网络上，得益于云计算行业的网络都是BGP网络，各大运营商访问服务器网络都可以获得一致的延时和带宽体验。 但是网络的设计上，很多人都会犯的错误，就是对业务系统对公网IP、私网IP的依赖，一个系统如果无法接受公网、私网IP的变动，会导致系统启动失败、运行失败，这就很糟糕。这会导致你不敢轻易的更换服务器或者IP，轻则无法享受一些采购上的政策优惠，重则会遇到IP因为某些不可抗力不得不改时的束手无策。 Web Server 我们常见的 Web Server 软件有很多，比如说：Apache HTTPD、Nginx、lighttpd、tomcat、LiteSpeed，不同的 Web Server 有着不同的动静态处理性能。 最有名的就是 Nginx 了，它的静态文件处理性能是众所周知的，它有着非常优秀的生态，对于新技术的支持会比Apache HTTPD 好得多，像 Lua支持、Brotli、TLS1.3等都支持的更早更好。所以 Web Server 的选择上 Nginx 是非常不错的选择，还有一些社区的扩展分支如 OpenResty、Tengine 等等。 不过整体使用下来，我发现 LiteSpeedTech 公司的 LiteSpeed Enterprise Web Server （简称LSWS）和 OpenLiteSpeed（简称OLS）会更适合 PHP 应用，它的 LSAPI 运行 PHP 以及 LSCache 对 PHP 应用有着非常好的支持，特别是针对 WordPress、 Magento、Joomla、PrestaShop、Drupal、MediaWiki、Laravel 有着很好的支持。大家可以在 LLStack 体验 LiteSpeed 环境。 非 PHP 应用如 JAVA、Node.JS 还是推荐 Nginx 或它的扩展分支来作为 Web Server。 PHP PHP 的性能调优上尽量选择最新的稳定版，比如说截止发稿PHP最新版是 7.4，那么我们可以使用 PHP7.4 或者 7.3 这两个版本。 目前 PHP 的版本策略是 2+1 模式，即 2 年活跃支持，1年安全支持。PHP 版本越新性能越好，同时安全漏洞也会更少。 PHP 之外，其他语言也是，JAVA 的话很多程序还在 JAVA 1.6 上运行。今年年初 Python2 已经停止官方维护了，但是仍有大量的应用基于 Python 提速的关键是两个缓存机制：字节码缓存和对象缓存。 字节码缓存 当一个 PHP 文件被解释执行的时候，首先是被编译成名为 opcodes 的中间代码，然后才被底层的虚拟机执行。 如果PHP文件没有被修改过，opcode 始终是一样的。这就意味着编译步骤白白浪费了 CPU 的资源。 此时 opcode 缓存就派上用场了。通过将 opcode 缓存在内存中，它能防止冗余的编译步骤，并且在下次调用执行时得到重用。设置 opcode 缓存只需要几分钟的时间，应用便会因此大大加速，实在没有理由不用它。目前 Zend 官方提供的 zend_OPCache 是效率最高的字节码缓存扩展。 对象缓存 有时缓存代码中的单个对象会很有用，比如有些需要很大开销获取的数据或者一些结果集不怎么变化的数据库查询。你可以使用一些缓存软件将这些数据存放在内存中以便下次高速获取。如果你获得数据后把他们存起来，下次请求直接从缓存里面获取数据，在减少数据库负载的同时能极大提高性能。 这个的具体实现会在下面 内存缓存加速 讲到 计算存储分离 当业务系统到一定规模后，数据会变成越来越重要的企业数字化资产。数据的范围很宽泛，首先是最核心的数据库里的数据（结构化数据）这个我们在下个主题讨论数据库的优化，还有就是企业的非结构化数据比如说头像、配图、附件等等。 非结构化数据虽然说并没有数据库来的重要，但是如果数据一旦丢失也会产生严重的影响。试想一个企业OA系统，如果存储的附件全部丢失，意味着这个企业的内部资料全部丢失了。在 WordPress 中，附件最重要的作用就是阅读体验，如果一个网站图片全部丢失读者几乎是没有兴趣进行阅读的。 虽然云服务器的云盘已经有99.9999999%（九个九）的数据可靠性了，但是它的性价比并不高，同时读取附件也会耗费服务器I/O性能。这时候将存储转移到阿里云的对象存储OSS则是最好的选择。虽然云盘支持扩容，但是它的弹性是不够的，比如说我买了1T的云盘，当我用到800G～900G我就会考虑开始扩容了，那么其实我一直会浪费10～15%的容量，而且前期我的容量也不是有高使用率的 对象存储可以做到99.999999999%（十二个九）的数据可靠性，同时没有容量和性能的上限、瓶颈，它最大的特点是按量付费，我使用了851G那么我就支付851G的成本即可，而不是我使用了851G却要支付1T的费用，并且用不到1T我就会要进行扩容。 将存储存放到OSS后，不仅提升了非结构化数据的读取性能还降低了成本。 如何在 WordPress 中使用OSS将本地化存储搬上云端请参考： 《将 WordPress 图像媒体全部迁移至对象存储，降低服务器存储压力》 CDN加速 前面我们讲了将非结构化数据存储到OSS，提升了读取性能还降低了成本，两全其美。 这里 CDN 也可以实现两全其美的事情，那就是在提升访问速度的同时还能降低网络成本。 为什么天猫超市、苏宁、京东购买的自营商品到货会那么快？我可以上午买下午到，半夜买上午到，这样办公白领的购物体验还是提升很多的，这都得益于就近仓储的优势，比如说我要买的商品的制造地是甘肃兰州，本来我要买就得从兰州发货，但通过一些自营电商购买，我在杭州滨江区，那么物流仓储就会从杭州富阳的仓储中心快速分配到末端配送站，然后分配快递小哥帮助我们配送。 CDN 其实也是这个逻辑，将用户要访问的非结构化文件就近存放到CDN的缓存节点，这样用户访问的速度就更快了。我在新疆喀什要访问一个华东1杭州地域的网站，这个跳数和延时都会很大，但是使用CDN后，那我就可以从乌鲁木齐的某个电信机房获取缓存文件，这样我的访问速度和延迟都会降低了。 然后CDN为什么还可以在提速的同时节约成本呢？如果要玩外服的游戏，我购买网游加速器还要花不菲的包月成本，为什么CDN不经帮我加速了，同时还能节省成本呢？这个解释还是可以用快读的模式来，咱们将东西从杭州寄到杭州，和杭州寄到新疆，哪个更便宜？肯定是路径更短的更便宜，网络访问路径短了，自然也能省钱。 WordPress 上使用 CDN 有很多丰富的插件，在OSS中提到的插件也可以直接使用CDN。 CDN 一个是加速非结构化数据的好手，OSS 是存储非结构化数据的大师，所以OSS+CDN是强强联手，非常好的搭档。 在 WordPress 主题目录下的 functions.php 文件中，加入以下代码实现CDN替换功能： //静态文件CDN加速 if ( !is_admin() ) { add_action('wp_loaded','mf8biz_ob_start'); function mf8biz_ob_start() { ob_start('mf8biz_aliyun_cdn_replace'); } function mf8biz_aliyun_cdn_replace($html){ $local_host = 'www.mf8.biz'; //源站域名 $aliyun_host = 'statics.mf8.biz'; //CDN加速域名 $cdn_exts = 'css|js|png|jpg|jpeg|gif|ico'; //扩展名（使用|分隔） $cdn_dirs = 'wp-content|wp-includes'; //目录（使用|分隔） $cdn_dirs = str_replace('-', '\-', $cdn_dirs); if ($cdn_dirs) { $regex = '/' . str_replace('/', '\/', $local_host) . '\/((' . $cdn_dirs . ')\/[^\s\?\\\'\"\;\>\<]{1,}.(' . $cdn_exts . '))([\"\\\'\s\?]{1})/'; $html = preg_replace($regex, $aliyun_host . '/$1$4', $html); } else { $regex = '/' . str_replace('/', '\/', $local_host) . '\/([^\s\?\\\'\"\;\>\<]{1,}.(' . $cdn_exts . '))([\"\\\'\s\?]{1})/'; $html = preg_replace($regex, $aliyun_host . '/$1$3', $html); } return $html; } } 站库分离 早期我们可以将数据库和应用放在同一台服务器上运行，但是前面讲到一旦到了后期就会出现运维的灾难。 数据库是一个业务系统的重中之重，特别是针对一些金融、电商类的场景，如果数据库一旦出错轻则业务暂停，重则会导致业务崩快。例如移动支付场景肯定不能接受数据库损坏的瞬间，买家已经付款并银行卡已经扣费，但是卖家并没有收到款项，这就对业务造成过影响了，如果这个消费数值是几亿元的量级，就有很大的问题了。 站库分离是很重要的步骤，将数据库和应用程序的运维分离开来。但是云计算时代，有了云数据库，这个工作就会变的愉快很多。首先调试数据库其实是比较难的，现在很多开发同学都会担任一些DevOps，但也只是开发者和运维的结合，但很少有同学还会点亮DBA（数据库管理专家）的技能，比如说设计一个数据库，我们要规划备份方案、调优方案等等，规划多少的RTO（丢多少）和RPO（丢多久）等等，让一个非专业的同学头大，同时企业聘请一个专业的DBA也会增加用人成本。 而云数据库就是一个数据库开箱即用的方案了，我们不用担心数据库遇到高危漏洞时的安全风险，云数据库做出升级方案，和云监控搭配的监控图标也可以很直观的反馈数据情况，以及 CloudDBA 功能，基于专家的规则经验，自动判断数据库问题。 云数据库的优势还有很多，篇幅限制就不展开讲太多了，大家可以去了解一下云数据库和PolarDB。 后者在完美兼容 MySQL、PostgreSQL 和高度兼容 Oracle 的技术上实现了更高的性能，MySQL 最高可达到 600%的性能提升，但相较RDS成本仅提升10%。 扩展工具： DTS，DTS 是一款支持多种数据源的可视化数据迁移工具，可以帮助我们快捷直观的将自建数据库的数据迁移至云数据库，也可以做数据同步订阅使用。 DBS，DBS是一款专业型的数据库备份工具，可以快捷的将数据库备份至OSS中，实时增量备份实现秒级RPO。 在 WordPress 中实现站库分离很简单，将源站数据库上的数据通过 DTS 或者备份恢复的方式迁移到云数据库即可。然后修改 wp-config.php 文件，将define( 'DB_HOST', 'localhost' );中的 localhost修改成云数据库的连接地址即可。 内存缓存加速 WordPress 使用 MySQL 数据库来缓存内部应用程序对象（导航栏、菜单栏等），生成这些对象的资源成本成本很高。由于数据库还处理页面请求的查询，因此它可能是最常见的性能瓶颈，并且经常导致加载时间增加。 Redis 是一个开源的键值对存储数据库，既可以用作内存级存储，也可以用作缓存。Redis是一种数据结构服务器，可以单独作为 NoSQL 数据库服务，也可以与关系数据库（如MySQL）结合以加快访问处理速度。当涉及对象缓存时，在像WordPress这样的动态网站上使用，该对象缓存可缓存重复的访问内容。 因为 Redis 是基于内存的服务，内存访问的速度和效率比就算是给予 NVMe SSD 的磁盘也来的更快，所以使用 Redis 来做为 PHP 的对象缓存来加速 WordPress 的效率会更好，访问速度更快，这在文章数极大的场景下网站的使用体验会好很多。 Redis 我们可以自建也可以购买阿里云的云数据库，早期如果成本考虑是可以自建在自己的服务器上的。如果是本机的 Redis Server，建议使用 UNIX Socket 的方式效率会比 TCP 来的更高。 在 WordPress 使用 Redis 作为对象缓存，需要 PHP 安装实现 phpredis 这个 PECL 扩展，不然的话会基于 predis 方式实现，这个效率没有 PECL 扩展效率来的高，然后安装相关的 Redis 对象缓存插件即可。 相关教程推荐： 《WP 使用走 Unix Sockets 的 Redis 作为对象缓存》 《使用云数据库 Redis 版为 WP 做缓存》 还有将 Redis 缓存应用到 Web Server 的方式，减少对 php 的请求来进一步提速，这适合能接受静态页面的CMS类网站，不太适合动态内容多的网站： 《用 Nginx+Redis Cache 给 WordPress 提速》 《LiteSpeed Cache for WordPress – 免费的超性能企业级缓存插件》 《为 WordPress 开启 LS-Cache 缓存》 负载均衡 云服务器的特性主要就是体现在横向、纵向的弹性扩容上，纵向的话其实很好理解就是我们单台 ECS 配置不够用了马上升级一下配置，不过这种场景比较适合于一个网站稳健的发展状态，而且波动不大。或者说服务器有较长时间的资源占用而非短时间的，比如说台风网肯定是 5~10 月这段时间访问量较高，那么我们就可以在春末的时候升一段配置，夏天再升级一段配置，初秋稍微降一点，秋末降至平稳状态。 但是如果我们是一个电商网站突然运营想搞一个秒杀活动，一个游戏公司要组织一场在线PK大赛。 这种情况下呢，都是瞬时遭遇的流量高峰和应用高占用，过了这段时间突然就回到了平稳的状态。如果我们一直以能处理瞬时高峰的配置长时间运行势必会造成大量的资源浪费，这时候就需要一个按量的横向扩容了。 横向扩容也就是增加服务器数量而非升级配置，但是我们需要将数个服务器整合成一个服务器集群，通过均衡负载 SLB 让服务器集群看起来就像还是“一台”服务器在进行操作，当然了均衡负载也不一定需要使用 SLB，也可以自建或者采购其他的均衡负载产品。然后每一台服务器都应该做到无状态服务，不可以保存应用的状态信息（如 session）和相关数据（如数据库、日志等）。如果应用中有保存状态信息需求，可以考虑把状态信息保存到伸缩组之外的独立的状态服务器、数据库（如 云数据库）和集中日志存储（如 日志服务）中去。 很多教程可能一开始就是负载均衡一步到位，这样对运维是有一定要求的，不利于新手架构学习。在做好计算存储分离、站库分离、内存加速（Redis共享session）后再做负载均衡的难度会显著降低。 相关教程推荐： 《配置自动横向扩展的同城双中心服务集群》 《使用SLB+DNS轻松实现网站的IPV6双栈兼容》 搜索请求优化 WordPress 默认搜索方式是LIKE 和 ％query％ 等查询的组合。其不允许进行模糊搜索，如果有用户犯了简单的拼写错误，就获得有效的搜索。WordPress 的另一个限制是，它只能搜索和匹配标题和内容中的单词，而不能与类别和分类法进行匹配。 同时搜索是非常消耗数据库资源的一种方式，并且搜索结果不会进行缓存，如果你想攻击一个WordPress网站，只需要对一个搜索结果页频繁进行F5就可以让数据库资源消耗到瓶颈后停止服务，这样整个WordPress网站都将无法提供服务。 同理其他应用程序也会遇到这个问题，因此我们会选择使用专业的搜索引擎来进行索引，并提供给用户更专业的结果。目前第三方的搜索引擎方案有百度的站内搜索（很久没更新，不支持HTTPS）、谷歌的CSE（国内无法访问）。因此我们可以选择自定义性和功能更丰富的开源搜索引擎 Elasticsearch。 在 WordPress 上接入使用 Elasticsearch 是非常方便的，0 coding。只需要安装 ElasticPress 插件并编辑 wp-config.php 文件: /** ElasticPress */ define( 'EP_HOST', 'http://127.0.0.1:9200' ); 定义一下 ElasticSearch 的地址即可使用。 安全架构 安全也是服务器架构中非常重要的一点，只要是暴露在公网上的业务就有可能成为被攻击的对象，因此我们需要积极的构建云上安全体系进行防御常见的安全攻击，同时也要保障自己的云产品不被劫持为肉鸡对外发送攻击加重互联网安全态势。 其实攻击者视角是来自方方面面的，360°无死角的盯着咱们的业务进行攻击，而安全又是一个典型的木桶的短板模型，即便其他的安全措施做的再好，只要存在一个明显的安全短板，就会导致整个业务系统的不安全。而防守者视角往往是单一的，通常是见招拆招式的的，甚至有些时候当安全事件已经发生了，很多人都无法及时做出对安全事件的反应。 这是我根据阿里云安全团队安全三步走的基础上修改来的云上安全体系构建路线图，本文我们重点聚焦云上安全第0步——安全基础建设。因为很多云上用户在没有做好第0步的时候就开始购买一些第一二步云安全产品，就会出现木桶短板效应，花费了高昂的费用却没有起到响应的安全作用。 推荐相关阅读： 《不花一分钱构建阿里云上第零步安全体系》 当然了在 WordPress 上也有很多可以免费体验的PHP软件级的WAF插件，帮助防御一定的攻击，提升网站安全性，不过相比阿里云WAF这样的专业性WAF肯定是有所欠缺的。 插件： SiteGuard WP Plugin、NinjaFirewall、WordPress Security、Wordfence Security 备份机制 很多用户会认为租用的阿里云ECS云服务器的云盘有 99.9999999% 的数据可靠性，这个是不是就意味着我放在云上的数据不会丢。这时候客户还会意识到说数据的三盘副本，一些客户在文件误删的时候就会说：“你们阿里云有三盘副本，我现在这个云盘里的文件我不小心误删了，那另外两个盘上的副本快取出来帮我恢复一下。” 其实这时候就有必要澄清一下，三盘副本主要是为了防止系统错误导致的文件丢失的情况，并不能防止因为误删除或者病毒进程删除文件导致的逻辑错误，具体如下图： 我们需要积极的通过构建快照来解决因为逻辑错误导致的数据丢失的问题。 阿里云的快照操作很方便，是完全图形化的且是中文界面的，并且支持手动或者自动方式创建快照，并且支持快照制作成镜像后跨地域复制到其他地域进行多维度容灾。同时，快照备份是存储在更高可靠且更具性价比的对象存储OSS上的，这个成本是非常可观的。 我们还可以单独将网站文件备份到 OSS 和 NAS 这样的更廉价存储的地方，做增量或者全量的备份。在数据备份上还是和数据库的数据可用性一样，规划设计RTO（丢多少）和RPO（丢多久），在这个道路上还是一个很长的路。 推荐阅读： ECS快照帮助文档 | ECS快照使用视频教程 《使用 AliCloud Duplicity 将服务器文件备份至 OSS》 在 WordPress 也有很多备份插件，支持FTP和S3协议（兼容阿里云OSS），可以用作方便的备份方式： UpdraftPlus、BackWPUp、BackUpWordPress 等等 日志分析 服务器日志很多人可能都将它看作是“鸡肋”，食之无用、弃之可惜，觉得他很占地方。很多存储买的比较小的服务器，它的磁盘经常会以为存储大量日志被占用，导致I/O异常，然后人会选择关掉日志。 其实日志有很多游泳的信息，包括服务器的状态、相关软件的报错信息、访客数据、访客行为，以及一些安全审计等等。日志很多人可能直接通过编辑器甚至是记事本直接打开，那这样用处确实是不大，所以一个好的架构师一定要学会分析日志，利用好日志。 一般来说 WordPress 日志包括：Web Server日志（Nginx、Apache、LiteSpeed 的日志）、PHP日志、数据库日志、邮件日志（如果有）、操作系统日志、WordPress Debug 记录和相关插件日志等等。 我们可以用阿里云的日志服务或者ELK三剑客之一的Logstacsh来进行分析，WordPress 日志开启，还需要修改 wp-config.php 文件，加入下面语句： define( 'WP_DEBUG_LOG', true ); //开启debug日志 define( 'WP_DEBUG_DISPLAY', false ); //隐藏debug消息到页面输出 define( 'SAVEQUERIES', true ); //将数据库查询保存到数组中，可以用于帮助分析，选填 如果大家不想用更专业日志分析工具，也可以通过如下插件快速实现，只不过专业日志是存储到服务器的，这个成本会比存储到 OSS 高的多： WP Security Audit Log、Simple History、User Activity Log、WP Log Viewer、Log-Hero 结语 架构的学习是漫漫长路，很多新人在学习架构的时候都会反馈缺少实践的平台，得益于 WordPress 丰富的生态，我们可以很好的利用它来结合各大软件，我这里指出的也只是一些基础思路，也欢迎大家指正错误的地方。 架构也是不是一定要套用的，也不是一尘不变的。比如说 WordPress 作为 CMS 的场景下可能不太有必要应用大数据，但是当 WordPress 安装 WooCommerce 插件成为一个电商网站后，其实就有可能有大数据个性化推荐的需求了。 我也看到也有 WordPress 网站被改造成一个咖啡自助系统，在完成点单后传输到物联网咖啡机上自动作出咖啡来，那么就可能一些物联网架构的需求了。 布置两个小作业，相关的思路还可以套用在同样是PHP 的 Discuz 和 微擎 上，根据我的实践这两个软件都可以实现上述架构。 可以在阿里云大学的 30分钟学会搭建高可用网站 和 零基础云上搭建高可用网站

12月12日，第六届DEAS数字娱乐产业年度高峰会于厦门隆重召开，阿里云边缘计算产品首席架构师刘强受邀参会，并在“开启5G元年新场景”主题板块中发表《边缘计算驱动科技“寒武纪”时代》演讲，分享边缘计算在当下企业办公、安防、物流等城市场景的关键作用。 “寒武纪”时代带来的启发 什么是“寒武纪”时代？“寒武纪”是6亿年前的一个时代，这个时代之前没有太多的复杂生物，但是由于“寒武纪”时代地球温度逐渐上升，为生物的生存创造了条件，所以这个时代之后在几百万年之间，出现了大量复杂生物的出现与爆发。总而言之，“寒武纪”时代生物大爆发正是因为温度这一基础条件发生了变化。 实际上，这一现象也在人类社会里不断的上演。比如，一百多年前，美国在铁路建设和电力设施大量的普及催生了第二次工业革命的发展，而第二次工业革命的发展催生了我们现在耳熟能详的可口可乐、通用电器、通用汽车等等这些百年老店，它们在短短15年时间内成为行业巨头，直到今天。 大约在2000年，在中国也发生了类似的事情，利用15年时间建成的全国铁路网络、通信网络，在这个过程当中，也产生很多新的公司，而且这些公司呈现出大者恒大、强者恒强的态势。2008年是3G元年，移动互联网逐渐映入眼帘，期间除了老牌的新浪、腾讯推出微博、微信，也有很多新的创新公司出现，比如游戏、泛娱乐公司大量的出现，它们都在移动互联网产业里占据了不可或缺的位置，而这个时期过后也鲜有进场机会。 所以，在刘强看来，一个新的时代到来必定产生新的格局，新的业务爆发，如果能够抓住机会，就意味着抓住这个时代最好的切入点，如果错过，就可能会失去后面的机会。 5G催生新技术、新场景、新经营 “今天我们走到了5G的元年，在5G的时代又会有什么“新生物”大爆发出现呢？”刘强说道。5G带来的基础条件的改变包括高速率、泛在网、低功耗、低时延等等，这些基础条件改变会创造什么样新的业务的场景呢？从人的需求本身来看，人与人的生活是以人与周围的人和物的生活互联互通、彼此发生关系为基本条件的，这个基本原理随着人类社会的发展至今，结果是大家基本都住在城市里，聚集效应使得城市的功能越来越强，规模越来越大，人们更喜欢住在城市里，城市的公交系统非常的发达、有良好的医疗条件、优质的教育等等，给人们提供更多的便利。所以这是一种天然的属性，就是80%的连接沟通活动是发生在城市这一级的。 那么对应的在IT基础设施、云计算层面，我们响应这个需求的方式是由中心云的模式迈向边缘云的模式，边缘云可以更加好地适应城市内部的运算。随着5G的到来，边缘云的价值也会变得越来越大。 随着5G传输速率的变快与边缘计算的应用，网络模式由局域网向互联网化的转变。比如，安防厂商可能从单个局域网的环境变成城市网的环境，借用数据通信网络连接能力穿起产品、解决方案闭环。再比如，在局域网生态中，IT领域基础设施层面X86的服务器、交换机、存储等等这些设备构成了基础设施，在操作系统、数据库层面也是这个时代的产物，对于应用层是OA、ERP这些软件是这个时代的产物。等到了互联网化这个时代，一切会被云所颠覆，比如云提供的IaaS分布式、虚拟化能力，PaaS层智能和大数据、上层的SaaS应用、移动办公等等。这都是5G时代会带来的从局域网到互联网化转变，会催生新的场景。 刘强表示：“5G到来，我个人认为或许经营的思路也会有一些新的改变，因为我们面对是万亿级的市场，从原来局域网的模式上升到通讯网络或者到互联网的网络里，快速把用户留存在自己网络里就变得非常重要。而云计算和互联网的某些运行模式为我们提供了参考，在互联网时代，大部分社交软件实际上是不收费的，它是靠广告、游戏、个性化展示等增值服务来赚钱，所以实际上形成明显的分界，就是基础的平台作为流量的支柱，上层有一些增值的业务来赚钱，这个是社交网络运营的形态。在云计算领域其实也有类似的形态，基础的计算资源和存储资源是云计算的基础产品，会不断释放红利，而上层开源软件、数据库等产品商业化来获取更多的附加价值，这些业务实际上代表着的是云计算的增值业务。 5G时代的时间窗也很短，客户从局域网迁移到互联网的过程中进入到了哪个网络就会成为这个网络里终身的用户。意味着我们可以在城市级的网络交换这个层面通过低价吸引海量客户入驻自己的网络，把客户接入到城市级的运算当中。上层再依靠增值业务的发展而盈利，比如说城域间、跨网间的网络交换业务，云计算、安防等业务，这些业务都会嵌入到5G的业务网之中，这是5G时代经营模式的转变。 当互联网具备局域网的网络性能后，原来IT领域万亿级的市场会扩大到十万亿级，为什么有这样一个跃升？因为在局域网的时代，数据的连接是局域网跟局域网之间的连接，如果上升到城市的级别，在城市进行运算的话就意味着数据跟数据之间的连接和计算都更多，同样数据之间产生的价值也会更多，整个产业的增值也会变得非常的明显，所以到十万亿级的市场是5G发展不可逆转的趋势。 阿里云5G边缘计算场景实践 在大趋势之下，阿里云积极布局并进行场景实践，在边缘计算基础设施层有服务器、交换机等；在计算层面层有基于飞天内容与边缘运维的操作系统和存储、网络等这些IaaS服务；在上层PaaS产品包括边缘存储、计算、容器、视频云等；延伸至行业应用包括云市场、企业软件、安防、车联网、物流等SaaS应用。 第一个是政企应用软件的场景，这个场景在IT时代更多是通过盒装软件的方式进行交付，在云的时代则通过SaaS化模式进行交互。SaaS化的交互模式具有更强的接入便利性、更经济的运维及交付成本、更快的响应速度，最终可以为客户创造价值。所以SaaS化交付模式以每年15%的市场增速在发展。阿里云有云市场，事实证明这种模式是非常健康。5G与边缘计算加速由局域网到城市级计算的转型，也加速了SaaS化企业应用软件时代的到来。 第二个场景是关于安防，安防场景经历了三个时代，2005年到2008年是解决数字化的问题，摄像头IP化、存储数字化。2009年到2015年是智慧城市项目的诞生，以区县级的视频联网为主，这个时代摄像头跟摄像头之间的运算依然相对比较孤立。2016年到至今，城市大脑不断推进，摄像头进入了智能化时代，每个摄像头是一个眼睛，把采集到的数据汇集到云端做更复杂的运算，必定会带来全新业务场景的诞生。 整个趋势是由原有系统封闭割裂、应用厂商锁定的阶段，发展到边缘计算和联网化使得系统互通更便利、基础设施资源更弹性、运营管理更便捷的阶段。城市级边缘计算会形成一个通用基础的计算平台，汇聚数据，调度服务。比如，在单个摄像头运的时代如果有走失儿童，需要通过人工方式逐个摄像头寻找，效率比较低，在边缘计算和联网化的时代，利用AI可以进行全盘查找，快速分析行为路径及衣着数据，大幅提升效率。5G的出现能够实现物联网网络能力的提升以及超低延时的数据传输，这会加速全新机器视觉时代的到来。 第三个场景是关于车联网的场景，这是阿里集团的一些实践，比如菜鸟物流园区内无人车运货、高校内无人车送货等等方案。把这个场景打开就是无人驾驶、车路协同。在局域网时代，交通运维系统可能是以路测系统为主，5G与边缘计算可以保障高稳定性、广覆盖以及瞬时响应的网络覆盖，同时也有助于无人车传感器、摄像头、毫米波雷达等终端数据更快地采集、汇总、分析及进行判断，进而更快指导无人车针对周围环境做出更智能、更精确地反馈，从而大幅提升自动驾驶的性能。 最后一个场景是关于物流场景中的扫码枪，它也在4G时代遭遇瓶颈。在物流系统中，扫码枪背后要承载的运算能力是非常多且复杂的。它背后承载着监控系统、传感控制系统、标签业务系统等交互协同，面临着快递标签上的急件、送货上门、拦截件、冷链、危险品等众多属性的辨别和与系统之间打通，同时因为有时间的限制，意味着在有限的时间内完成复杂的运算，对计算效率要求非常高。 在4G时代，这种运算只能是在局域网环境内完成，仓储中心可以做运算，但是仓储中心内部的运算是满足不了全国货物的需求，货物还做不到真正智能。随着5G时代网络延迟大幅度的提升，以及计算能力向城市侧、用户侧的下沉，原来在局域网里实现不了的运算皆可实现。如果一个小时有十万包的吞吐量，扫码枪从扫的那一刻开始到最后的结果，整个过程需要在3毫秒内完成，这恰恰是5G和边缘计算可以赋能物流场景的能力。所以， 5G边缘计算也会为物流行业注入新的能量。 除此之外，5G会使得超高清的赛事和游戏直播、移动在线教育会更加普及，同时远程医疗、远程工业等企业级应用成为可能，VR、AR、3D等创新视听娱乐模式也将被激活，以上包含更大的数据量同时需要更快的信息传输速度的业务场景，都是边缘计算很好的应用场景。比如将部分VR图像渲染卸载到边缘节点上，来实现高质量、低延时的VR应用。 未来，阿里云将持续与产业合作伙伴深度链接，发挥阿里集团与生态优势，做好5G时代的边缘计算基础设施建设，同时通过创新产品解决方案研发来赋能各行业，助力更多客户在5G时代抓住机遇。 点击了解边缘节点服务