初涉移动端设计和开发的同学们，基本都会在尺寸问题上纠结好一阵子才能摸到头绪。我也花了很长时间才弄明白，感觉有必要写一篇足够通俗易懂的教程来帮助大家。从原理说起，理清关于尺寸的所有细节。由于是写给初学者的，所以不要嫌我啰嗦。现象首先说现象，大家都知道移动端设备屏幕尺寸非常多，碎片化严重。尤其是Android，你会听到很多种分辨率：480x800,480x854,540x960,720x1280,1080x1920，而且还有传说中的2K屏。近年来iPhone的碎片化也加剧了：640x960,640x1136,750x1334,1242x2208。不要被这些尺寸吓倒。实际上大部分的app和移动端网页，在各种尺寸的屏幕上都能正常显示。说明尺寸的问题一定有解决方法，而且有规律可循。像素密度要知道，屏幕是由很多像素点组成的。之前提到那么多种分辨率，都是手机屏幕的实际像素尺寸。比如480x800的屏幕，就是由800行、480列的像素点组成的。每个点发出不同颜色的光，构成我们所看到的画面。而手机屏幕的物理尺寸，和像素尺寸是不成比例的。最典型的例子，iPhone3gs的屏幕像素是320x480，iPhone4s的屏幕像素是640x960。刚好两倍，然而两款手机都是3.5英寸的。所以，我们要引入最重要的一个概念：像素密度，也就是PPI（pixelsperinch）。这项指标是连接数字世界与物理世界的桥梁。Pixelsperinch，准确的说是每英寸的长度上排列的像素点数量。1英寸是一个固定长度，等于2.54厘米，大约是食指最末端那根指节的长度。像素密度越高，代表屏幕显示效果越精细。Retina屏比普通屏清晰很多，就是因为它的像素密度翻了一倍。倍率与逻辑像素再用iPhone3gs和4s来举例。假设有个邮件列表界面，我们不妨按照PC端网页设计的思维来想象。3gs上大概只能显示4-5行，4s就能显示9-10行，而且每行会变得特别宽。但两款手机其实是一样大的。如果照这种方式显示，3gs上刚刚好的效果，在4s上就会小到根本看不清字。在现实中，这两者效果却是一样的。这是因为Retina屏幕把2x2个像素当1个像素使用。比如原本44像素高的顶部导航栏，在Retina屏上用了88个像素的高度来显示。导致界面元素都变成2倍大小，反而和3gs效果一样了。画质却更清晰。在以前，iOS应用的资源图片中，同一张图通常有两个尺寸。你会看到文件名有的带@2x字样，有的不带。其中不带@2x的用在普通屏上，带@2x的用在Retina屏上。只要图片准备好，iOS会自己判断用哪张，Android道理也一样。由此可以看出，苹果以普通屏为基准，给Retina屏定义了一个2倍的倍率（iPhone6plus除外，它达到了3倍）。实际像素除以倍率，就得到逻辑像素尺寸。只要两个屏幕逻辑像素相同，它们的显示效果就是相同的。Android的解决方法类似，但更复杂一些。因为Android屏幕尺寸实在太多，分辨率高低跨度非常大，不像苹果只有那么几款固定设备、固定尺寸。所以Android把各种设备的像素密度划成了好几个范围区间，给不同范围的设备定义了不同的倍率，来保证显示效果相近。像素密度概念虽然重要，但用不着我们自己算，iOS与Android都帮我们算好了。如图所示，像素密度在120左右的屏幕归为ldpi，160左右的归为mdpi，以此类推。这样，所有的Android屏幕都找到了自己的位置，并赋予了相应的倍率：ldpi[0.75倍]mdpi[1倍]hdpi[1.5倍]xhdpi[2倍]xxhdpi[3倍]xxxhdpi[4倍]各型号iPhone的倍率比较简单，我们后面会讲到。那么Android手机那么多，具体怎么分？哪些手机是几倍的倍率呢？我们先看一张表，这是友盟2014年10月到2015年03月的数据：就目前市场状况而言，各种手机的分辨率可以这样粗略判断。虽然不全面，但至少在1年内都还有一定的参考意义：ldpi如今已绝迹，不用考虑mdpi[320x480]（市场份额不足5%，新手机不会有这种倍率，屏幕通常都特别小）hdpi[480x800、480x854、540x960]（早年的低端机，屏幕在3.5英寸档位；如今的低端机，屏幕在4.7-5.0英寸档位）xhdpi[720x1280]（早年的中端机，屏幕在4.7-5.0英寸档位；如今的中低端机，屏幕在5.0-5.5英寸档位）xxhdpi[1080x1920]（早年的高端机，如今的中高端机，屏幕通常都在5.0英寸以上）xxxhdpi[1440x2560]（极少数2K屏手机，比如GoogleNexus6）自然地，以1倍的mdpi作为基准。像素密度更高或者更低的设备，只需乘以相应的倍率，就能得到与基准倍率近似的显示效果。不过需要注意的是，Android设备的逻辑像素尺寸并不统一。比如两种常见的屏幕480x800和1080x1920，它们分别属于hdpi和xxhdpi。除以各自倍率1.5倍和3倍，得到逻辑像素为320x533和360x640。很显然，后者更宽更高，能显示更多内容。所以，即使有倍率的存在，各种Android设备的显示效果仍然无法做到完全一致。单位不难发现，真正决定显示效果的，是逻辑像素尺寸。为此，iOS和Android平台都定义了各自的逻辑像素单位。iOS的尺寸单位为pt，Android的尺寸单位为dp。说实话，两者其实是一回事。单位之间的换算关系随倍率变化：1倍：1pt=1dp=1px（mdpi、iPhone3gs）1.5倍：1pt=1dp=1.5px（hdpi）2倍：1pt=1dp=2px（xhdpi、iPhone4s/5/6）3倍：1pt=1dp=3px（xxhdpi、iPhone6）4倍：1pt=1dp=4px（xxxhdpi）单位决定了我们的思考方式。在设计和开发过程中，应该尽量使用逻辑像素尺寸来思考界面。设计Android应用时，有的设计师喜欢把画布设为1080x1920，有的喜欢设成720x1280。给出的界面元素尺寸就不统一了。Android的最小点击区域尺寸是48x48dp，这就意味着在xhdpi的设备上，按钮尺寸至少是96x96px。而在xxhdpi设备上，则是144x144px。无论画布设成多大，我们设计的是基准倍率的界面样式，而且开发人员需要的单位都是逻辑像素。所以为了保证准确高效的沟通，双方都需要以逻辑像素尺寸来描述和理解界面，无论是在标注图还是在日常沟通中。不要再说“底部标签栏的高度是96像素，我是按照xhdpi做的”这样的话了。Web怎么办移动端页面的绝对单位仍然是px，至少代码里这么写，但它的道理也和app一样。由于像素密度是设备本身的固有属性，它会影响到设备中的所有应用，包括浏览器。前端技术可以善加利用设备的像素密度，只需一行代码，浏览器便会使用app的显示方式来渲染页面。根据像素密度，按相应倍率缩放。可以通过这个测试页面http://greenzorro.github.io/demo/basic/响应式断点.html来看看你的移动设备屏幕宽度，这是逻辑像素宽度。以iPhone5s为例，屏幕的分辨率是640x1136，倍率是2。浏览器会认为屏幕的分辨率是320x568，仍然是基准倍率的尺寸。所以在制作页面时，只需要按照基准倍率来就行了。无论什么样的屏幕，倍率是多少，都按逻辑像素尺寸来设计和开发页面。只不过在准备资源图的时候，需要准备2倍大小的图，通过代码把它缩成1倍大小显示，才能保证清晰。实际应用大家最关心的还是实际运用，画布该怎么设置。我们就iOS、Android、Web三个平台来分别梳理一下。不过在这之前，我要为使用PS进行设计的朋友介绍一个小技巧。之前我说过，我们要以逻辑像素尺寸来思考界面。体现到设计过程中，就是要把单位设置成逻辑像素。打开PS的首选项——单位与标尺界面，把尺寸和文字单位都改成点（Point）。这里的点也就是pt，无论设计iOS、Android还是Web应用，单位都用它。当然，各平台单位名称还是要记住的。这里我们用的只是它的原理，不用在意名称。要调节倍率，则通过图像大小里的DPI来控制。这个DPI，其实就是PPI，像素密度。有个常识大家都知道，屏幕上的设计DPI设成72，印刷品设计DPI设成300。为什么是这两个数字？首先说300，这和人眼的分辨能力有关。由于1英寸是固定长度，每1英寸有多少个像素点决定了画质清晰程度。之前说过，这就是像素密度，也就是DPI。DPI达到300以上，其细腻程度就会给人真实感，像真实世界中的物件。相反，DPI只有10的话，在你一个食指指节大小的长度内只有10个像素，这明显就是马赛克了。所以印刷品要设成300，才能保证清晰。再说72，这有一定的历史原因。最早的图形设计是在mac电脑上进行的，mac本身的显示器分辨率就是72。PS中把图像DPI也设成72，就能保证屏幕上显示的尺寸和打印尺寸相同，便于设计。72的PC显示器分辨率逐渐成为一种默认的行业标准，这套规则就这么沿用下来。现在回到正题，我们怎么通过DPI来调节倍率？既然屏幕本身的分辨率是72，DPI设成72刚好是1倍尺寸，那设成72的两倍就是倍率为2的屏幕了，就这么简单。下面来看看3个平台各自的画布设置：iPhoneiPhone的屏幕尺寸各不相同，我说的是逻辑像素尺寸，这确实是让人很头疼的事情。如果想用一套设计涵盖所有iPhone，就要选择逻辑像素折中的机型。从市场占有率数据来看，目前最多的是iPhone5/5s的屏幕。倍率为2，逻辑像素320x568。上升势头最猛，未来有望登上第一的是iPhone6的屏幕。倍率为2，逻辑像素375x667。按照这两种尺寸来设计，都是比较主流的做法。可以兼顾短一些的iPhone4s，大一点的6plus也不会过于空旷。不过在切图的时候要注意，由于iPhone6plus的3倍图是由2倍图放大而来，所以位图要注意保证清晰。Android都说Android碎片化严重，但它现在反而比iOS好处理。因为如今的Android屏幕逻辑像素已经趋于统一了：360x640，就看你设成几倍了。想以xhdpi为准，就把DPI设成72x2=144。想以xxhdpi为准，就把DPI设成72x3=216。对于那些比较老的低端机，宽度是480px的那批，画面确实会小一些，显示内容会更少。稍微留意一下，重要内容尽量保持在界面中上部分。当然，这些机型不出一年就会被边缘化，基本淘汰。现在能运转的也是当作功能机在用，软件多了必卡无疑，用户体验无从谈起。不作考虑也是OK的。Web手机端网页就没有统一标准了，比较流行的做法是按照iPhone5的尺寸来设计。倍率2，逻辑像素320x568。这样的做法比较实在，倍率2的屏幕无论在iOS还是Android方面都是主流，而且又是2倍屏幕中逻辑像素最小的。所以图片的尺寸可以保持在较小的水平，页面加载速度快。当然，缺点就是在倍率3的设备上看，图片不是特别清晰。如果追求图片质量，愿意牺牲加载速度，那么可以按照最大的屏幕来设计。也就是iPhone6plus的尺寸，倍率3，逻辑像素414x736。 总结移动端的尺寸比PC端复杂，关键就在倍率。但也正因为倍率的存在，把大大小小的屏幕拉回到同一水平线，得以保证一套设计适应各种屏幕。站在这条水平线的角度看，会发现它很好理解。以上就是本文的全部内容，希望对大家的学习有所帮助，也希望大家多多支持站三界导航。
刚接触seo这个行业，在网上囫囵吞枣的看了一些教程。其中必然会说到的是网站静态化，那么为什么网站需要静态化呢？网上答案基本一致，对于非技术出身小编的我来说都也就是个概念，特别是其中安全性这个点，更是不知所云。由于不了解安全性重要性的问题，所以一直对于网上说的有点呲之于鼻。比如里面颇为重要的一点就是url更规范化，可读性更高，我也不是很认同对于人来说，虽然静态化的url看在眼里却是会比较舒服，但是也见谁真的为喜欢一篇文章刻意去记住该文章所在的目录和该文章的id编号，甚至能记住你的域名都不多。至于对于蜘蛛来说，这就有点牵强了，蜘蛛是一个程序，动态化的url和静态化的其实在他眼里都只是一条超链接，就好像人为了收藏该文章，会把文章收为书签，对于书签来说这两个url有区别吗？又有人说，静态化url可以清晰显示网站的结构，但是我对于百度的技术还是很信任的，我相信这个问题在百度眼里也就是添加几行代码的事而已，那为什么还要静态化呢，直至到我接手牧童康体这个网站。 据说在我未接手之前，给黑了一次，页面挂上了隐藏的黑链，网站已经给k得索引剩下4个页面了。黑链已经删除了，我接手的时候只剩下这张图片说明网站给黑客“临幸”过：首先当然会出一套方案了，什么h1标签、nofollow、alt标签之类的，最后少不了网上必说的静态化。虽然不知为什么一定要这样，但对于新手的我来说，大神说得都对。刷刷的一天完成，下班前交给了老大走人。第二天一上班给老大叫进去说讨论下方案。讨论愉快的进行着，突然老大问了一句，静态化必要吗？当场差点问懵了，总不能回答网上大神都说是必要的，我只好回忆网上的内容混过了过去。不过既然不懂了，就要去学习。网站给黑，这无疑是安全性问题，静态化刚好也涉及安全性问题这点。从这个方向去深入去了解应该没问题了。在网上找答案，群里问高手，经过一番功夫，终于是了解静态和动态网站的区别，原来动态每次访问都要链接数据库，给人有了注入的可能性，而静态化后其页面完全脱离了后台，让黑客无从注入。当然有用户可以登录的还是有注入的可能的，但是只有一条路径防范起来也相对容易。再看一下网站的ftp，更是触目惊心，网站几乎天天有人要”临幸”，注入日志几乎没有停过：要改变这个还是得静态化，目前已经把方案交给建站公司了，应该会很快得到解决的。我个人觉得静态化最重要的还是安全，百度会对为静态化的网站不友好，非是技术原因不能解决蜘蛛对网站的检索而是鼓励网站去实行静态化，像牧童康体这样的动态网站，虽然暂时是安全的，但是天天给人注入，终有一天会成功的。
一、能用阶段早期业务流量还不是很大，渠道网关系统业务逻辑也很简单，一句话总结就是：让用户在交易的时候，能顺利把钱给付了。做的事情可简单概括成3件：发起支付请求、接收支付成功通知以及用户要求退款时原路退回给用户的支付账户。这个阶段系统实践比较简单，主要就是“短、平、快”，快速接入新的第三方支付渠道并保证能用。系统架构如图1。 二、可用阶段在系统演进初期的快速迭代过程中，接入的第三方支付渠道不多，系统运行还算比较平稳，一些简单问题也可通过开发人员人工快速解决。但随着接入的第三方支付渠道不断增多，逐渐暴露出一些新的问题： (1)所有的业务逻辑都在同一个物理部署单元，不同业务之间互相影响（例如退款业务出现问题，但是与此同时把支付业务也拖垮了）； (2)随着业务流量的增大，数据库的压力逐渐增大，数据库的偶尔波动造成系统不稳定，对用户的支付体验影响很大； (3)支付、退款等状态的同步很大程度上依赖第三方支付渠道的异步通知，一旦第三方支付渠道出现问题，造成大量客诉，用户体验很差，开发、运营都很被动。针对(1)中的业务之间互相影响问题，我们首先考虑进行服务拆分，将之前一个大的物理部署单元拆成多个物理部署单元。有两种明显的可供选择的拆分策略：按照渠道拆分，不同的第三方支付渠道独立一个物理部署单元，例如微信一个部署单元，支付宝一个部署单元等；按照业务类型拆分，不同的业务独立一个物理部署单元，例如支付业务一个部署单元，退款业务一个部署单元等。考虑到在当时的流量规模下，支付业务优先级最高，退款等业务的优先级要低；而有些渠道的流量占比很小，作为一个独立的部署单元，会造成一定的资源浪费，且增加了系统维护的复杂度。基于此，我们做了一个符合当时系统规模的trade-off：选择了第2种拆分策略—按照业务类型拆分。 针对(2)中的DB压力问题，我们和DBA一起分析原因，最终选择了Master-Slave方案。通过增加Slave来缓解查询压力；通过强制走Master来保证业务场景的强一致性；通过公司的DB中间件Zebra来做负载均衡和灾备切换，保证DB的高可用性。 针对(3)中的状态同步问题，我们对不同渠道进行梳理，在已有的第三方支付渠道异步通知的基础上，通过主动查询定时批量同步状态，解决了绝大部分状态同步问题。对于仍未同步的少量Case，系统开放出供内部使用的API，方便后台接入和开发人员手动补单。在完成上述的实践之后，渠道网关系统已达到基本可用阶段，通过内部监控平台可以看到，核心服务接口可用性都能达到99.9%以上。演化之后的系统架构如图2。三、柔性可用阶段在解决了业务隔离、DB压力、状态同步等问题后，渠道网关系统度过一段稳定可用的时期。但架不住业务飞速增长的压力，之前业务流量规模下的一些小的系统波动、流量冲击等异常，在遭遇流量洪峰时被急剧放大，最终可能成为压垮系统的最后一根稻草。在新的业务流量规模下，我们面临着新的挑战：(1)随着团队的壮大，新加入的同学在接入新的渠道或者增加新的逻辑时，往往都会优先选用自己熟悉的方式完成任务。但熟悉的不一定是合理的，有可能会引入新的风险。特别是在与第三方渠道对接时，系统目前在使用的HTTP交互框架就有JDKHttpURLConnection/HttpsURLConnection、Httpclient3.x、Httpclient4.x（4.x版本内部还分别有使用不同的小版本）。仅在这个上面就踩过好几次惨痛的坑。 (2)在按业务类型进行服务拆分后，不同业务不再互相影响。但同一业务内部，之前流量规模小的时候，偶尔波动一次影响不大，现在流量增大后，不同渠道之间就开始互相影响。例如支付业务，对外统一提供分布式的支付API，所有渠道共享同一个服务RPC连接池，一旦某一个渠道的支付接口性能恶化，导致大量占用服务RPC连接，其他正常渠道的请求都无法进来；而故障渠道性能恶化直接导致用户无法通过该渠道支付成功，连锁反应导致用户多次重试，从而进一步导致恶化加剧，最终引起系统雪崩，拒绝服务，且重启后的服务还有可能被大量的故障渠道重试请求给再次击垮。 (3)目前接入的第三方支付渠道，无论是第三方支付公司、银行或是其他外部支付机构，基本都是通过重定向或SDK的方式引导用户完成最终支付动作。在这条支付链路中，渠道网关系统只是在后端与第三方支付渠道进行交互（生成支付重定向URL或预支付凭证），且只能通过第三方支付渠道的异步通知或自己主动进行支付查询才能得知最终用户支付结果。一旦某个第三方支付渠道内部发生故障，渠道网关系统完全无法得知该支付链路已损坏，这对用户支付体验造成损害。 (4)现有的渠道网关的DB，某些非渠道网关服务仍可直接访问，这对渠道网关系统的DB稳定性、DB容量规划等带来风险，进而影响渠道网关系统的可用性，内部戏称被戴了“绿帽子”。 (5)对于退款链路，系统目前未针对退款异常case进行统一收集、整理并分类，且缺乏一个清晰的退款链路监控。这导致用户申请退款后，少量用户的退款请求最终未处理成功，用户发起客诉。同时由于缺乏监控，导致这种异常退款缺乏一个后续推进措施，极端情形下，引起用户二次客诉，极大损害用户体验和公司信誉度。为最大程度解决问题(1)中描述的风险，在吸取踩坑的惨痛教训后，我们针对第三方渠道对接，收集并整理不同的应用场景，抽象出一套接入框架。接入框架定义了请求组装、请求执行、响应解析和错误重试这一整套网关交互流程，屏蔽了底层的HTTP或Socket交互细节，并提供相应的扩展点。针对银行渠道接入存在前置机这种特殊的应用场景，还基于Netty抽象出连接池（ConnPool）和简单的负载均衡机制（LB,提供RoundRobin路由策略）。不同渠道在接入时可插入自定义的组装策略（扩展已有的HttpReq、HttpsReq或NettyReq），执行策略[扩展已有（Http、Https或Netty）Sender/Receiver]，解析策略（扩展已有的HttpResp、HttpsResp或NettyResp），并复用框架已提供的内容解析（binary/xml/jsonparser）、证书加载（keystore/truststoreloader）和加解密签名（encrypt/decrypt/sign/verifysign）组件，从而在达到提高渠道接入效率的同时，尽可能减少新渠道接入带来的风险。接入框架的流程结构如图3。为解决问题(2)中渠道之间相互影响，一个简单直观的思路就是渠道隔离。如何隔离，隔离到什么程度？这是2个主要的问题点：如何隔离考虑过将支付服务进一步按照渠道拆分，将系统继续做小，但是拆分后，支付API的调用端需要区分不同渠道调用不同的支付API接口，这相当于将渠道隔离问题抛给了调用端；同时拆分后服务增多，调用端需要维护同一渠道支付业务的多个不同RPC-API，复杂度提高，增加了开发人员的维护负担，这在当前的业务流量规模下不太可取。所以我们选择了在同一个支付服务API内部进行渠道隔离。由于共用同一个支付服务服务API连接池，渠道隔离的首要目标就是避免故障渠道大量占用AP连接池，对其他正常渠道造成株连影响。如果能够自动检测出故障渠道，并在其发生故障的初期阶段就快速失败该故障渠道的请求，则从业务逻辑上就自动完成了故障渠道的隔离。 隔离到什么程度一个支付渠道下存在不同的支付方式(信用卡支付、借记卡支付、余额支付等)，而有些支付方式(例如信用卡支付)还存在多个银行。所以我们直接将渠道隔离的最小粒度定义到支付渠道->支付方式->银行。基于上述的思考，我们设计并实现了一个针对故障渠道的快速失败（fail-fast）机制：将每一笔支付请求所附带的支付信息抽象为一个特定的fail-fast路径，请求抽象成一个fail-fast事务，请求成功即认为事务成功，反之，事务失败。 在fail-fast事务执行过程中，级联有2个fail-fast断路开关：静态开关，根据人工配置（on/off），断定某个支付请求是否需快速失败。动态开关，根据历史统计信息，确定当前健康状态，进而断定是否快速失败当前支付请求。动态断路开关抽象了3种健康状态（closed-放行所有请求；half_open-部分比例的请求放行；open-快速失败所有请求），并依据历史统计信息（总请求量/请求失败量/请求异常量/请求超时量），在其内部维护了一个健康状态变迁的状态机。状态变迁如图4。状态机的每一次状态变迁都会产生一个健康状态事件，收银台服务可以监听这个健康状态事件，实现支付渠道的联动上下线切换。 每一笔支付请求结束后都会动态更新历史统计信息。经过线上流量模拟压测观察，fail-fast机制给系统支付请求增加了1~5ms的额外耗时，相比第三方渠道的支付接口耗时，占比1%~2%，属于可控范围。渠道故障fail-fast机制上线之后，结合压测配置，经过几次微调，稳定了线上环境的fail-fast配置参数。在前不久的某渠道支付故障时，通过公司内部的监控平台，明显观察到fail-fast机制起到很好的故障隔离效果。 为解决问题(3)中支付链路可用性监测，依赖公司内部的监控平台上报，实时监控支付成功通知趋势曲线；同时渠道网关系统内部从业务层面自行实现了支付链路端到端的监控。秒级监控支付链路端到端支付成功总量及支付成功率，并基于这2个指标的历史统计信息，提供实时的支付链路邮件或短信报警。而在流量高峰时，该监控还可通过人工手动降级（异步化或关闭）。这在很大程度上提高了开发人员的核心支付链路故障响应速度。为解决问题(4)中的“绿帽子”，渠道网关系统配合DBA回收所有外部系统的DB直接访问权限，提供替换的API以供外部系统访问，这给后续的提升DB稳定性、DB容量规划以及后续可能的异步多机房部署打下基础。 针对问题(5)中退款case，渠道网关系统配合退款链路上的其他交易、支付系统，从源头上对第三方渠道退款异常case进行统一收集、整理并分类，并形成退款链路核心指标（退款当日成功率/次日成功率/7日成功率）监控，该部分的系统实践会随着后续的“退款链路统一优化”一起进行分享；随着上述实践的逐步完成，渠道网关系统的可用性得到显著提高，核心链路的API接口可用性达到99.99%，在公司的917大促中，渠道网关系统平稳度过流量高峰，并迎来了新的记录：提交第三方渠道支付请求的TPS达到历史新高。且在部分渠道接口发生故障时，能保证核心支付API接口的稳定性，并做到故障渠道的自动检测、恢复，实现收银台对应渠道的联动上下线切换。同时，通过核心支付链路支付成功率监控，实现第三方渠道内部故障时，渠道上下线的手动切换。至此，基本保证了在部分第三方渠道有损的情况下，渠道网关系统的柔性可用。演化后的此阶段系统架构如图6。四、经验与总结在整个渠道网关系统一步步的完善过程中，踩过很多坑，吃过很多教训，几点小的收获： 1.坚持核心思想，拆分、解耦，大系统做小，做简单； 2.系统总会有出问题的时候，重要的是如何快速定位、恢复、解决问题，这是一个长期而又艰巨的任务；3.高可用性的最大敌人不仅是技术，还是使用技术实现系统的人，如何在业务、系统快速迭代的过程中，保证自我驱动，不掉队；4.高流量，大并发对每一个工程师既是挑战，更是机遇。
互联网时代，网站是企业进行全网营销的必备品。可对于网站建设，企业往往不知从何下手，云指建站的客户经常会遇到这样的问题：自己完全没有规划，找一些企业简介、产品资料，和几幅照片，交给建站的人，费钱费力费时间，最后建出来的网站总达到不到自己要的效果。那么企业应该怎么样策划自己的网站? 第一：明确网站定位根据自己的产品、销售渠道和销售对象等情况，明确自己的网站是信息服务型、销售型、销售服务型或是综合型。面向企业客户的网站和面向个体消费者的网站是完全不一样的，即使是面向个体消费者的网站，也并非所有都需要销售商品，而且并不是所有产品都适合在网上销售。比如，面向企业客户的网站的重点是其在企业间合作过程中的作用，而不需要像面向消费者的网站那样千方百计去增加浏览率，另如可口可乐、柯达都没有在网上销售产品，网站只是它们树立形象，提供顾客服务的一个工具，是它们整体营销战略的一部分。 第二：了解目标市场你的客户是企业还是个体消费者，他们来自何处?他们信息化程度如何，经常上网吗?他们主要使用哪些语言?主要希望了解哪些信息?他们的购买水平如何?主要使用哪种浏览器?当然，最初建网站时不可能了解这么细致，网站内容需要随着对消费者了解的深入而逐步调整。 第三：明确自己的竞争优势你的网上、网下竞争对手是谁?(网上竞争对手可以通过搜索引擎查找)，与他们相比，你在商品、价格、服务、品牌、配送渠道等方面有什么优势?竞争对手的优势你能否学习?如何根据自己的竞争优势来确定你的营销战略?第四：你如何为客户提供信息?你的网站信息来源在哪里?信息是集中到网站编辑处更新、发布还是由各部门自行更新、发布?集中发布可能安全性好，便于管理，但信息更新速度可能较慢，有时还可能出现协调不力的问题。比如，某产品已经售缺，但网站编辑却不知道，仍在网上销售该产品。北京几家大百货公司的网站就经常出现消费者付了款却取不到货的事情。 第五：规划好收款与配送事宜如果你是一个销售型网站，顾客购买你商品的频率如何?你是否能接受货到付款或在线支付?你的商品如何配送?配送的成本、时间如何考虑?这五个环节都考虑清楚了，你的网站的功能也就基本齐了，接下来企业就要有专人负责网站这块，也就是网站SEO。 第六：专人运营我们要的不是网站，而是网站带来的价值。网站运营要有目标、有步骤和有方法地做，要聘请专职人员来做，也可以将这块外包出去找专人托管。总比建一个死站要强得多，如果每天只有几个、十几个的点击率，完全没有什么作用。以上就是企业在规划网站时要注意的事情，希望能对大家有所帮助!
医疗行业作为一个特殊、敏感的行业，做好网站建设是一件很不容易的事情。随着互联网的高速发展，医疗行业在做好线下医疗服务的同时，也渐渐将目光投向互联网领域。踏足互联网，医疗行业可以将自身优势资源整合到网站中去，为大家提供病理知识、在线咨询或者预约就诊服务等。告别传统的口碑式、传单式推广，利用互联网这一海量的用户资源，建设医疗行业自身品牌网站，树立企业形象，拓展自身业务和用户渠道，为企业带来高价值利益。 那么如何做好医疗行业的网站建设呢?本期为大家分享一些在建站过程中需要注意的东西和建站经验，希望能给大家带来帮助。 一、网站定位医疗行业下分也有很多的行业，比如医疗器械、医疗咨询、医疗诊疗服务等，所以我们在建设网站的时候要考虑到这些不同行业的定位问题。专注于自身服务建设，将自身产品的着重点放大，这样医疗行业的网站建设就有一个明确的定位分析，接下来做起具体开发来就会更加得心应手。需要注意的是，在网站建设中要留意将网站内容和栏目规划等与你的网站定位相符合，好比你的网站定位是以出售腰椎病治疗仪为主的医疗器械网站，那么在建设过程中一定要围绕这一定位来建设，这样才能凸显你网站的专业性。医疗行业的网站虽然好定位，但是仔细研究里面的东西，学问还是很深的。二、内容建设这部分主要看你的网站定位了，网站内容建设围绕网站定位来编写是最好的选择。医疗行业的知识专业性比较强、范围比较广、且学术价值很高，要求里面的内容一定要真实且精确无差错。这方面的内容来源我们可以参考相关权威机构或者学术文献等，一定要确保信息内容真实可靠。前些日子的魏则西事件，就是给我们一个很好的警醒例子。特别是在诊疗案例介绍、医疗器械功效说明等方面，尤为要检查仔细，不然一旦再次发生什么事件，那么对于企业就不仅仅是网站下线这么简单的事了。除了这些信息内容确保真实外，我们在进行内容建设过程中还要注重信息的质量，不能含有那些没有营养价值的文章信息，不能给用户带来价值的文章信息，用户不想访问或者页面停留时间很短，也就不会有网站访问流量，搜索引擎也难以抓取你的网站信息。因而发表高质量的文章信息，吸引用户的阅读访问是我们需要着重考虑的问题。比如我们网站主要以医疗资讯类服务为主，那么我们的文章侧重点就要贴近这一主题，可以发布一些专业性强的病理知识，养护攻略等。只有能够给用户带来价值的文章内容建设，才能提升网站访问量，提高权重与排名。三、用户体验这个话题永远不会过时，不论是APP、网站、产品或服务，都在讲用户体验。用户体验是一个非常重要的东西，对应到我们医疗行业网站建设中来，那就是要满足用户需求。让用户在访问你的网站过程中是一个舒心的体验而不是带着苦恼来依旧带着苦恼离开。用户体验涉及到很多方面，比如网页打开加载速度，网站配色布局、网站信息实用性等。医疗行业虽然行业特殊，但是它还是离不开基础的网站建设方面的知识，至于用户体验，我们在实际建设开发过程中着重注意一下就好。 另外，站三界导航还想给大家分享的一点就是作为医疗行业，一定要培养和用户之间的彼此信任感。这不仅是用户对你企业网站的肯定，更是对你企业本身价值服务的认同。其中网站的信息真实、服务质量是关键，决不能有欺诈、欺骗用户的行为。这一点，我们可以从魏则西事件中多多吸取教训，这也是对我们整个医疗行业敲响了一个警钟啊!
创建缓存实例 缓存服务管理入口位于网易蜂巢首页的缓存服务选项，点击「缓存服务」，显示当前用户的所有缓存实例列表。 你可以此创建实例，设置实例，查看实例状态等。点击实例名称，进入实例详情。 创建实例你可以在「缓存服务」主界面，点击「创建缓存实例」来创建一个新的缓存实例，创建实例界面如下所示，操作十分便捷，只需填写实例名称、实例密码，选择实例引擎和实例内存容量，然后点击「立即创建」按钮，即可开始创建实例。 实例创建时，我们采用了默认参数，你之后可以在「设置」中修改。设置实例你可以在以下两处修改实例设置：在「缓存服务」主界面，点击该实例「操作栏」的「设置」按钮； 在「缓存服务」主界面，点击该实例名称，进入「缓存实例详情」页面后，点击「设置」按钮。 在设置实例页面可以修改以下配置： 内存容量-蜂巢提供在线修改内存容量，不停服即可完成内存容量修改，且不丢失缓存数据。Redis参数-修改实例配置的操作同样在线完成。设置完成以后，点击「提交设置」即可。 设置实例页面同时提供实例删除功能，点击「删除实例」并确认，即可将实例删除。缓存实例管理在「缓存服务」主界面，点击该实例名称，进入缓存实例详情页面。这里包含了「性能监控」、「详细信息」和「操作日志」功能，并提供「设置」按钮。性能监控显示当前实例的系统和Redis的性能监控曲线。监控项蜂巢提供以下12项监控数据的曲线图展示：时间范围与聚合区间蜂巢提供过去3小时、24小时、48小时和7天的时间范围快捷键，点击即可查看对应时段的监控数据;同时支持自定义时间范围，点击「自定义」设定任意时间范围，查看对应时段的监控数据。 不同时间范围对应不同聚合区间供选择：实时监控若通过快捷键设定时间范围为「过去3小时」或「过去24小时」，我们提供实时监控功能。勾选/取消勾选各性能监控数据曲线图右上角的「实时监控」，即可开启/关闭监控数据实时刷新。统计指标缓存服务性能监控统计指标均以平均值作为统计指标。 查看监控数据在性能监控数据曲线图中，将鼠标移至数据节点，可查看该点的详细监控数据和聚合时间戳。 详细信息实例详情页面顶部展示实例名称、内存用量、网络地址、运行状态等信息。提供「设置」按钮修改实例信息。点击「详细信息」标签，可以查看更多实例详情。 清除数据基本信息版块「内存容量」右方，提供「清除数据」功能，您可以通过该按钮清空实例内存。操作日志在实例详情页面，点击「操作日志」标签，查看该实例的所有管理操作，包括配置修改、扩容等。
交互设计的5个常见错误艳丽的图片、顺畅的鼠标悬停效果和意外的动画，不再那么容易引起用户注意了。但难题却没有解决——如何创造令人愉快的用户体验，让用户面带笑容完成转化？如果你对常见的设计陷阱有所警觉，就能更少犯错。为了方便——可能也为了让你知道你不是独自一人——以下总结了最常见的交互设计误区。 1、铺天盖地的创新网页设计师都非常有创造力。我们希望通过作品来表达自我。我们总是在寻求创新的设计方法来脱颖而出。但是，当涉及到交互设计时，创新并不总是好事。甚至会给你的网站带来坏的影响。用户渴望熟悉的事物，他们总是会遵循一些特定的操作方式。 RandyJ.Hunt，Etsy的创意总监和ProductDesignfortheWeb作者，清晰地陈述过：“嘿，设计师：别再TM自作聪明了。”在文章中，他详细解释了为什么别在网页设计上过分热衷创新。 以Iotorama网站为例。它挺漂亮，音乐深情，但是看着满屏幕移动的球，用户不知所措。不要误解我的意思，这个项目非常出色，超级有创造力！我喜欢这个大胆的创意，但它一点也不直观。 还有一个例子。SafetyontheSlopes项目背后的创作者想到一个巧妙的交互式图形，用来警告用户冬季运动的危险。非常创新，同时也很直观、有趣、令人印象深刻。 2、令人困惑的导航“不要自作聪明”的准则也可以沿用到导航上。有些设计师试图使用折衷的名称来寻求新颖。比如Chijoff网站就让用户不知道他们究竟提供什么，如何聘请他们。需要看上好一阵子，才能理解“共同创造”页面实际上就等同于“服务”。甚至还有，通读整页后用户仍然不知道该怎么做……页面末尾只有个小注册表单用来获取最新的行业新闻和提示！在“联系”页面也没有表单，只有邮编和邮箱地址。使人们联络或聘用他们非常困难。 你能猜出“Universe”在MaisonMargiela网站中是什么意思吗？实际上它链接到他们的Facebook主页。谁能想到？相反，看看legworkstudio的网站。它的创意与超凡令人震撼。导航非常清晰不含糊。用户绝对不会迷路。 3.杂乱无章有一段时期，网站都试图把一切可能的东西摆上台面。那些日子已经一去不复返，但是很多网站仍然在犯这个错误。看看这个在线商城：设计师试图坚持一种单色配色，但是大量颜色不同的色块、logo和字体，在这个页面上就足够让用户步履蹒跚。搜索框有着醒目的文案：“那么，今天你想要什么？”，但整个布局的外观和感觉非常过时。 EBay是主要在在线零售商之一，在这点上做得不错。没有用产品图片、促销和各种行动召唤塞满整个页面，而是保持它干净简洁，强调他们确实希望用户首先关注的东西，并附上清晰的提示，接下来该怎么做。4.注意对比，大哥！对比是创造视觉层级、吸引用户注意特定元素的最重要的方式之一。在网页设计中，对比不仅仅意味着颜色使用，也包括尺寸、形状和位置。这个网站是最简单生动的例子。他们做到了统一一致，但整体背景和按钮并不够吸引人，尤其是在订购按钮上。 相比来看这个。颜色选用很接近，但结果却完全不同。而且，创新的滚动效果，流畅地介绍了产品的新功能——反光材料。很酷，对吧？ 5.忽视表单样式表单设计是用户体验最基本的部分。每个网站都有一个目标——无论是树立榜样、直接售卖产品或是提供信息。不幸的是，许多网站有着光鲜的首页，却宁可用长表单和复杂的验证码来使用户厌烦致死。除非用户有强烈的先导动机，否则他们就会离开。 有了JCF这样的有效的跨浏览器的解决方案，是时候忘记那些丑陋的默认表单元素了，转向一种更加沉浸的用户体验吧。另一件气人的事，是表单要求太多信息，或者没通过完善测试。例如sketchybusiness.io的表单高亮显示了所有的空白框，甚至包括非必填项。 如果你看了sketchybusiness.io的表单，你绝对会喜欢它的鼠标悬停和按钮按下状态。而且，“别害羞”的提示文案增加了一丝亲切幽默的感觉。最后……不要懒于测试！对你重要的对于顾客未必重要。他们在哪里遇到问题卡住？是导航、奇特的视觉差滚动效果、还是长时间加载的视频？用户测试的最大好处之一，是你可以通过用户的视角来观察，关注他们的需求、做出改进。不要抑制你的创造力。要牢记网站访客可能会感到困惑和沮丧。你见过最糟的交互设计错误是什么？可以在评论中分享你的想法和故事。 交互设计需要注意什么 1、一看就懂这个说起来挺好理解的，就是让用户直观的理解产品功能，而事实上，这个概念包含的东西太多了，这里简单说下常见的2点。图形化：图片相对文字来说，所承载的信息更直观，也更能渲染气氛，给用户留下更深的印象。常见于各种小图标，比如下载按钮，通常会看到用一个向下的箭头来表示。对于重要的按钮来说，一般会将其图形化，就算没有采用小图标来辅助表达，也会采用“色块”来讲“文字”图形化。文字：刚说了图形化，其实并不是说，所以文字都可以用图形来替代，文字的存在还是很有必要的，特别是一些具有“独特性”的功能按钮，用户接触得少，没有相关的理解经验，难以图形化。大多数情况，文字不会删去，而会保留，辅助说明图形内容。文字还有一个很常见的问题，就是文字太多，用户没有耐心去看，或者看完后没有理解到所表达的核心。在设计的时候，要将文字删了再删，把“介绍文段”变成“产品口号”，有助于用户更好的了解产品。用词也很重要，如果产品定位是专业人员使用，那么可以使用一些专业术语，如果不是，请把各种专业术语“平民化”。这一点，更偏向产品的表面形式，这需要交互设计师跟视觉设计师相配合，把产品页面中，需要突出的重点，更视觉设计师沟通好。这一步，也是用户感觉这个产品好不好用，最先接触到的一层，即从视觉效果反馈的结果。 2、一用就对这点可以说是”一看就懂“的骨架，更多涉及产品的框架，让用户眼中的产品跟设计的产品一样。归纳：同类功能归到一起去，这就像电商网站的导航，把各种商品归纳分类。在这里，交互设计师需要根据需求档，整理产品的框架，然后把同一类型的功能归到一起去。归纳说起来挺容易的，但是做起来涉及的因素就比较多了。经常看到一些产品，把同一个功能，重复出现在同个页面中，这种做法，不一定是不合理的。比如：登陆功能，一个页面经常有多个入口，一般也是合理的。在工作中，最常遇到产品经理想要突出某个新产品，明明这个产品功能应该归到A页面，但是产品经理要求去B页面宣传，这时候就要留意，这个位置是否合理了。（这里要展开也讨论的话，都可以单独写一篇了，这里就简单举个例子：在电商里，如果把“手机套”放到“手机页面”去宣传，这里不一定是框架错了，如果把“手机套”放到“电脑页面”去宣传，这里的框架就有问题了。）一致性：这是交互设计最基础的知识之一，保证产品各种元素的一致性，不要让用户迷茫。比如标题的一致性，同一个功能，这里用A来表达，到了另一个页面，也要用A来表达。这里保障用户不会在使用过程中迷茫的基础。除了产品本身要保持一致性之外，在于产品所属的行业来说，这点还有一些有趣的方面可以讨论。对于产品的同行，特别是该行业中的老大，他们的设计是怎样的，这点需要交互设计师去了解清楚。因为用户长期使用这些产品，会养成一些操作习惯，比如现在很多信息类APP，下拉代表刷新页面，如果你设计的信息类软件，没有这个功能，那么在用户体验上，就会有所影响。 这点说白了，就是要搭建合理的结构框架，也是交互设计师工作的核心之一。保障用户操作顺畅，就靠它了。不过这里的标题“一用就对”，其实也不太严谨，因为产品一般都允许用户“试错”，用户可以通过错误操作，来学会使用产品。这里就引出了下一点反馈的内容了，当然，这个错误不能是“致命错误”。 3、别发呆了这点主要讲的是“反馈”，反馈也是交互设计的一个基础知识，涉及的范围挺广，但是核心就是要让用户别发呆，了解当前的操作，明白怎么去操作。错误各种错误操作的反馈提醒，这点需要交互设计师去发现，一个产品可以存在的各种情况，简单点说，就是找茬，还不能找太少。比如：留言超过100个字符怎么办？再极端点，服务器空间不够，保存不了留言怎么办？用户短期内持续留言，服务器超负荷怎么办？这些情况都需要交互设计师考虑好，当然有些涉及开发编程的内容，这部分内容就需要跟相关技术人员沟通下。考虑后，还需要给出适当的视觉提醒，比如，提醒“你刚刚已经留言了，我们会尽快回复，如需补充内容，请30秒后重试”。 等待漫漫的等待，是大多数用户无法忍受的事，如果还没有适当的提醒，用户基本不会继续等待。对于长时间的等待，最好有具体时间倒计时，而不是以单纯进度条的方式。而对于1-5秒之类的短时间等待，有时候采用纯进度条的方式会带来意外的收获。比如在游戏的跳转过程，因为读取数据需要等待，而这个过程大概要2-3秒，这时候，如果采用读秒的方式，用户容易产生烦躁，特别是需要重复操作时，容易让用户觉得，游戏没优化好，怎么这里还要等待2-3秒啊；如果采用进度条的方式，用户会把对游戏加载慢的原因，怪罪到自己的设备配置低。导航导航相对于产品的游园指南，除了告诉用户有什么东西外，还承担着用户的指南功能，时刻告诉用户，当前位置在哪，不要让用户迷路了。这也是交互设计的基础之一，适当的指引，别让用户发呆。反馈虽然也是属于表面层，但是这部分工作却是交互的重点之一。 4、总结一看就懂，通过视觉上的优化，让用户更直观的理解产品功能一用就对，通过产品框架上的优化，让用户更顺畅的使用产品别发呆了，通过用户的眼睛，让用户开开心心使用产品小技巧： （1）设计好一个产品后，把文字重新读一篇，思考，如果这段文字删了，会不会对用户使用造成影响，不会的话，那就删了吧。（2）随便打开一个页面，然后看看有没有合适的“当前位置”指南，会不会迷路，如何返回之类的。 （3）重新检查一次里面的用词/图标，是否一致。 （4）常见的遗漏情况：软件/硬件（兼容性问题比较常见）；网络状态（无网、超时、慢等）；转场（过程是否可以取消，是否有反馈等） （5）大必杀，找几个“新用户”（没有接触过该产品的人），看他们操作。写在最后，情感化设计，从我大学开始，就一直对这块内容很感兴趣，而如今作为一名初级交互设计师，我觉得情感化设计可以更好的融入产品之中去，就比如各个网站的404页面，这个页面的设计也间接表达了各个网站的情怀。
创建数据库实例RDS服务管理入口位于蜂巢首页的数据库服务选项。点击「数据库」，即可显示你的所有RDS实例列表，包括普通实例和只读实例。你可以在该界面进行实例创建、安全组管理等操作，此外还可以对具体实例进行设置、创建只读实例或提升只读实例角色（即提升只读实例为普通实例）等操作。点击「实例名称」，即可进入实例详情界面，如下图所示：创建实例在数据库主界面，点击「创建实例」创建一个新的RDS实例。创建实例的界面如下图所示。首先填写实例名称、选择数据库引擎、实例规格和设置网络类型，然后点击「确认」按钮，开始创建实例。实例创建时，蜂巢对实例的复制类型、备份类型、数据库参数和安全组等采用了默认参数和配置，你可以在「设置实例」中修改这些配置。 创建只读实例数据库主界面显示了各个实例的概要信息。如果实例是一个高可用实例，则在实例的「操作」列会显示「创建只读」链接。点击「创建只读」，即可为实例创建一个只读实例，如下图所示：只读实例的创建界面中，数据库引擎和源实例一致，不可更改，其余内容与创建实例相同，如下图所示：提升只读实例角色在数据库的主界面，点击实例名称右侧的箭头（如果存在），可以查看该实例的只读实例。对于只读实例，「操作」列提供了「提升角色」的功能，如下图所示。点击「提升角色」并确认，能够解除只读实例与源实例的关系，将只读实例变成一个普通的非高可用实例。 设置（修改）实例某一指定实例的设置页面有两处入口： 1.在数据库的主界面，点击该实例在「操作」列的「设置」链接，如下图所示： 2.在数据库的主界面，点击该实例的名称，进入该实例的「实例详情」页面，再点击「设置」按钮，如下图所示：设置实例页面提供了复制类型、备份类型、数据库参数和安全组等各项配置的修改操作，并可选择将修改设定为「立即生效」或「定时生效」。如果你选择定时生效，还需要选择「生效时间」。设置完成以后，点击「确认」即可。各项配置的详细说明如下： （1）复制类型蜂巢提供同步和异步两种复制类型，推荐使用同步复制：如下图所示： （2）备份类型你可以选择「增量备份」或「全量备份」。在选择了备份类型后，还可以对「备份周期」、「备份时间」等进行设置，如下图所示： （3）参数组在参数组设置中，你可以修改数据库的配置。页面中只显示用户最常修改的参数，要查看和修改更多的参数，点击「更多设置」即可。 （4）安全组点击「修改安全组」可以为实例配置安全组，从而限制能够访问实例的主机，如下图所示：在「设置实例」中，你只能新建或绑定已存在的安全组。迁移外部数据库蜂巢的外部数据库迁移功能支持多线程数据库备份和恢复，也支持基于业务负载的自适应迁移和迁移失败的重试。此外，蜂巢提供了较为全面的迁移参数检查，提高了迁移数据的成功率。目前，蜂巢提供外部MySQL实例的迁移功能。本文将以有公网IP的外部MySQL数据库实例迁移至蜂巢RDS为例。前提条件开始迁移前，务必检查以下内容：1.请确保外部数据库实例拥有test数据库，没有则新建空白test数据库即可； 2.若使用增量迁移，请确认外部数据库实例已开启binlog并设置server_id（目前server_id不能设置为0或1）； 3.若需要迁移权限，确认外部数据库实例与RDS实例权限没有冲突或者覆盖。迁移限制：目前在迁移5.1.41以下的MySQL版本时会出现失败场景，若遇到，请提蜂巢工单解决。目前正在适配外部实例版本为MySQL5.7的场景，RDS的MySQL5.7版本也即将推出。请等待完成适配后再迁移MySQL5.7版本到RDS；不支持迁移名称中包含「；」符号的数据库；不支持迁移MySQL系统库，如information_schema、performance_schema、#bak_database或data_dictionary、mysql中的general_log和slow_log表等。 其他说明：在导出外部实例数据阶段，会临时修改外部实例MySQLInnoDB参数innodb_old_blocks_time，完成数据导出或导出失败时，RDS会自动将其设置回原值；在将数据导入RDS实例阶段，RDS实例的sync-binlog、innodb_flush_log_at_trx_commit、log_slow_queries参数均会进行临时优化，完成数据导入或导入失败时，会自动将其设置回原值。创建迁移账号建议新建一个拥有相应权限的账号进行数据迁移。登录MySQL客户端，使用如下命令创建账号并赋予权限：复制代码代码如下:GRANTallprivilegesON[数据库名].[表名]TO'[期望创建的用户名]'@'[用户地址]'IDENTIFIEDBY'[期望设置的密码]';方便起见，本例中直接赋予数据库所有表的全部权限：「GRANTallprivilegesON*.*」；[用户地址]可以是IP地址、计算机名、域名，如果想从任意地址连接，使用「%」即可；重要：该帐号拥有所有权限，出于安全考虑，数据迁移完成后，请删除该账号或直接删除本地数据库。获取数据库列表登录蜂巢控制台，选择「数据库」，点击「迁移外部数据库」按钮：进入「获取数据库列表」步骤，需要输入待迁移的外部数据库IP地址、端口、数据库账号以及密码等信息，如下图所示，输入完毕后，点击「下一步」：如果连接失败，请检查以下内容：1.迁移账号权限； 2.账号、密码、IP地址、端口； 3.MySQL数据库版本须高于5.1.41；4.外部数据库实例拥有test数据库，没有则新建空白test数据库即可。选择待迁移的数据库连接外部数据库成功后，开始「选择待迁移的数据库」，这里显示了该数据库实例内的所有数据库，如下图所示。蜂巢支持一次性迁移同一实例下多个数据库，选择所需迁移的数据库名称，点击「下一步」：不支持迁移名称中包含「；」符号的数据库；不支持迁移MySQL系统库，如mysql中的general_log和slow_log表、information_schema、performance_schema、#bak_database或data_dictionary等。参数设置选择完数据库之后，进入「参数设置」步骤，如下图所示。具体的参数详情，请参见参数说明，在确认参数无误后，点击「下一步」发起迁移操作。注意：点击「下一步」后，默认会进行参数预检查，包括实例连通性、各个参数设置是否正确等，如果发现错误，蜂巢会显示出错信息，你可以进行相应修改后重新点击「下一步」。 参数说明1.迁移类型 （1）增量迁移增量迁移包括全量迁移和增量复制两个阶段。完成全量迁移后，会将迁移过程发生的数据变更同步到目标实例，如果迁移期间进行了DDL操作，那么这些结构变更不会迁移到目标实例。 （2）全量迁移将源实例迁移对象的结果定义及数据全部迁移到目标实例。迁移过程中，为了保证数据一致性，非事务表会被锁定，锁定期间这些表无法写入，锁定时长依赖于这些表的数据量大小，在这些非事务表迁移完成后，锁才会释放。 （3）结构迁移将源实例迁移对象（数据库、表）的结构定义（schema）迁移到目标实例。支持结构迁移的对象包括：表、视图、触发器、存储过程、存储函数等。 （4）权限迁移表示是否迁移源实例mysql.user表中的用户账号及权限到目标实例。RDS默认会取消所迁移权限中的Super权限。2.导出并发度表示启用多少个线程来同时导出表中的数据。请合理选择数据导出线程数，系统默认为2个，建议刚开始使用暂先不超过3个。 3.导入并发度表示启用多少个线程来同时导入表中的数据。RDS的数据导入线程需要根据RDS本身的存储介质性能进行合理规划。系统默认为2个，蜂巢的经验表明：2至4个线程一般来说已能够达到最大数据写入性能。 4.持锁超时时间表示进行数据导出时，允许对源实例加读锁（通过执行flushtableswithreadlock获取读锁）的时长，单位为s。注意，该值的设置会极大影响迁移，设小会导致迁移出错，设大的话需要关注是否对外部实例业务产生影响。 5.负载监控阈值表示从源实例导出数据时，允许导出线程select数据的最大负载，通过threads_running数值来衡量，如果该参数超过阈值则数据导出暂停，降到阈值以下时再继续。系统默认的监控项为300，如果外部实例压力较大，连接数较多，请合理选择监控项，并适当增加监控项。 6.创建新实例系统预检查无误后，显示如下「创建新实例」页面，即可进行数据迁移，此时只需填写新实例名称，选择合适的内存及存储空间后，点击「开始迁移」即可，数据库列表会自动生成迁移的数据库实例。 注意：需要确保迁移中创建的RDS实例有足够的空间用于迁移外部实例数据，可以通过设置存存储空间来进行调整。如果迁移失败，可以通过数据库实例列表中的「查看进度」查看原因。并根据系统出错提示，参照参数说明适当调整参数，最后点击「重试」即可。 如果不确定如何调整参数，建议提工单联系技术人员协助处理。
网站建设完整的网页设计包括头部，中间内容以及页脚设计三大部分，但许多建站者都会犯同一种错误，认为用户看头部重于页脚，于是忽略了页脚的重要性，造成头重脚轻的不协调结果，影响了整个网站的用户体验。 事实上，用户在浏览网站时对页脚也有一定的认知习惯，通常哪些信息会出现在页脚似乎已经形成了一种惯性，方便他们快速从网站的页脚中找到需要的信息，既然有被用户关注的点，那么对页脚的设计就不可掉以轻心，下面站三界导航小编就和大家分享一些关于网站页脚的设计技巧。 1、不要过于复杂。 页脚和页头的设计有所区别，它并不需要跟页头的导航栏或者BANNER图设计那样过多的注重交互性以及个性化，反而是简洁有力的页脚更加有利于用户体验。通常采用极少的色彩元素并和网站整体风格一致，尽量避免图片背景形式，如需让内容显得丰富些，就选择图标和文字结合的形式来展现，且内容也不宜过多，应简洁。 2、必要的信息不能少。 在浏览网站时，可以发现，大多数网站的页脚包含了企业简单业务介绍，联系信息，版权保护以及其它关联网站等等，当用户在网站上没有发现明显的联系方式，他们基本上都会把网页拉到页脚寻找信息，能让他们快速找到目标内容可以减少网站跳出率。 3、合理安排链接。 页脚内容对排布和分类要求较高，毕竟所占据的网站板块区域较小，因此要遵循以简洁明了的形式展示最直接和全面的内容，无论是网站基本内容的目录，还是联系方式，有或者是友情链接，最好进行组织分类，通常情况下，这些内容都是以概括的形式展示，更多详细内容以链接跳转的形式，对此要合理安排好链接，保证好用户体验，以防出现死链或者空链。 4、避免头重脚轻。 有些网站在建设的过程中并没有明确的页脚概念，往往把页头做得很耀眼，但是整站往下拉，却没有页脚的踪影，又或者是将页脚看作最次要的一部分，所使用的字体小，内容粗略，且没有将文字与背景对比度考虑在内等等，无形中就造成了用户不愉快的阅读体验，按照用户的浏览习惯，从网站页头浏览下来，体验效果都还不错，但一到页脚就一头雾水，这种头重脚轻的现象就造成了用户不好的印象。 5、去掉冗余的装饰。 有些网站建设认为页脚的信息内容过于简单则需要强调重点，但是往往这些“强调”会成为页脚设计中的累赘，譬如给链接加上下划线，字体采用特殊效果等等，事实上更多的是造成网站页面的杂乱，因此这些冗余的装饰最好统统去掉，干净整洁反而是一种美。 6、充分利用空间的同时注意留白。 网站页脚的设计是在有限的空间内展示最精辟的内容，对于这部分的空间要充分利用起来，对要使用的图标，文字，图片等内容进行排版设计，但在安排这些元素的同时要懂得留白，避免出现密密麻麻的内容扎堆情况，否则影响网站美观的同时也产生了用户阅读困扰。 页脚作为网站建设中重要的一部分，也是建站中不容忽视的一大内容板块，它能为网站传达很多的信息内容，掌握对它的设计技巧还能帮助网站提升用户体验度，因此别忘了它存在的作用和价值。
如今网站建设行业的竞争越来越大。价格战对于建站行业来说似乎已经打响。不同的建站公司，对于网站建设的报价也各不相同，有的几百或者几千，有的报价则几万甚至十几万。不同的价格的背后，往往预示着网站质量的千差万别。下面我们就来分析一下其中千差万别的质量到底体现在哪里，一起来看看吧!第一点、网站的设计水平有些企业对于网站的整体版面要求并不是特别高，因而有些网络公司会因此会降低网站版面设计要求。在南阳网络公司里任职美工的工作人员，其中是专业级别的并不多，专业网站设计师与会使用设计软件的普通美工，制作出来的网站，其设计水平是不同的，当然会使用设计软件的普通美工设计出来的版面制作的网站价格自然会比较便宜。 第二点、不同的网站建设方式随着互联网的发展，现在网上早已有很多免费的网站mu板及对应的程序代码了。有些网络公司建站就是为了能够快速，他们通常喜欢去找一些类似行业的网站mu板代码，然后对网站上的图片，名称及地址做个改变。然后这样的一个网站就制作好了，问客户收几百块钱就了事。很多客户认为这类网站价格便宜，当你在网上看到很多类似网站时，你就会知道，为什么你的网站会如此便宜。 第三点、营销策划能力其实也不能这么说，作为一个有实力的网络公司，一般建站都需要进行营销策划的。但是，并不排除有些网络公司对营销策划这块没有做建设性分析。做好营销策划，重要的是要考虑企业所处行业的发展趋势以及客户如何使用这些产品，还要对企业同行对手的情况进行一些考察，这样制作出来的网站才能更加符合企业的发展战略，才能更好使得企业去迎合客户，并着力体现企业优于、区别于同行竞争对手的特点。而便宜的网站在这方面自然不会去做一些分析，省去这个流程，自然会省去很多费用。 第四点、网站优化的水平便宜的网站并不会为网站设置搜索关键词的，即便是设置了搜索关键词，由于你的网站有太多类似站，因而排名也很难做好。而这类网站根本就不好做优化，价格自然比较便宜。 第五点、网站的技术编程水平程序员们的编程，主要是帮助网站建设成功，并要通过技术手法保障客户的机密文件的。有些程序员技术水平有限，很容易使制作的网站存在安全漏洞，那么一旦有人利用漏洞上传木马，那么浏览者可能就会因浏览这样的网站而使电脑中毒，后果相信大家也都想得到。 第六点、网站兼容性的考虑很多便宜的网站对不同的浏览器兼容性测试不好，而这些问题很容易造成网站看起来四分五裂，错位变形比较厉害。那么这样的网站自然不会得到更多用户的支持。 第七点、网站对细节的把控网站制作不仅是技术活，也是细节活，如果不能从细节处制作网站、服务网站，相信细节也会给网站带来很多这样那样的损失。 第八点、不同的售后服务为了给网站制作降低成本，很多网络公司对于网站的售后服务并不着重做，甚至有些公司根本没有售后。我公司对于售后工作还是比较看重的，起码每月都会给客户回访，客户有什么问题也可在平时及时咨询。在互联网时代低质量的网站如何与对手竞争的分析就介绍到这了，大家可以参考学习一下，希望会对大家有所帮助!欢迎大家继续关注站三界导航其他信息!
中国互联网举报中心