二者有这么几点区别：
1第一服务器本身的归属权。云服务器是指由云提供商提供的服务器资源，服务器本身属于云提供商，用户可以购买云服务上的资源，按自己需要购买。而你所说的香港服务器，应该是属于你自己的服务器，放在香港你公司建设的数据中心，或者是位于香港的IDC机房中。还有一种可能是香港服务器，是云提供商提供的，你选择的是云提供商位于香港的数据中心中，那么如果是这样，服务器的归属权还是云提供商的，你只能购买其云服务器的服务。
2服务器的管理问题。云服务器提供适用于不同业务场景的实例类型，如通用型、本地存储型、内存优化型、IO优化型等，不同类型的实例在CPU、内存容量、存储介质、存储容量、网卡数量等维度有不同的配置，自由搭配。选好后，直接在云上启用，就能使用，不用的时候关闭即可，很d性。而如果是自己购买服务器，放在香港IDC机房中，那么你就需要雇佣系统工程师和管理员，负责服务器的配置、维护、监控等工作，而且服务器的计算资源不用，也只能闲置着。
3成本上，云服务器能按需购买和释放资源，对于成本紧张的企业而言，云服务器是很好的选择，而且不用担心后期服务器的维护；而自己的服务器，需要考虑前期的采购，在IDC机房上架后，服务器进行配置，应用后还要考虑服务器的管理和维护等工作，还有服务器资源闲置的损耗，如果不在意成本，又要在香港开展业务，可以自己购买服务器建数据中心，或放在IDC机房。
4安全性上，看你的业务情况了，如果你对安全性很重视，或者公司有相关安全合规的要求，必须放在自己的数据中心中，那就只能自己购买服务器和存储等资源了。如果对安全性不那么敏感，完全可以选择云服务器。
希望对你有帮助。
期货网站应该涉及大量数据交互。因此对IO性能和CPU性能要求很高。
建议买带了IO优化的系列Ⅱ，CPU最好八核及以上，数据盘一定要选择SSD云盘，100G起吧
带宽的话建议3M起，如果访问量很大可以5M起
其他没啥主意的。cpu/带宽使用正常，磁盘IO占用过高，建议你检查服务器当时时间点是否有读写进程任务导致（Windows服务器任务管理器—性能—资源监控器—磁盘查看磁盘活动进程和磁盘读写，Linux服务器可以通过top，iostat等命令查看），你也可以检查数据库日志检查你的数据库是否存在慢查询、死锁、全表扫描导致，或者你可以通过使用云监控监控进程的磁盘IO读写。如果遇到问题你可以通过阿里云的售后支持-提交工单咨询。大数据并发处理解决方案：
1、HTML静态化
效率最高、消耗最小的就是纯静态化的html页面，所以尽可能使网站上的页面采用静态页面来实现，这个最简单的方法其实也是最有效的方法。但是对于大量内容并且频繁更新的网站，无法全部手动去挨个实现，于是出现了常见的信息发布系统CMS，像常访问的各个门户站点的新闻频道，甚至他们的其他频道，都是通过信息发布系统来管理和实现的，信息发布系统可以实现最简单的信息录入自动生成静态页面，还能具备频道管理、权限管理、自动抓取等功能，对于一个大型网站来说，拥有一套高效、可管理的CMS是必不可少的。
2、服务器分离
对于Web服务器来说，不管是Apache、IIS还是其他容器，是最消耗资源的，于是有必要将与页面进行分离，这是基本上大型网站都会采用的策略，他们都有独立的服务器，甚至很多台服务器。这样的架构可以降低提供页面访问请求的服务器系统压力，并且可以保证系统不会因为问题而崩溃，在应用服务器和服务器上，可以进行不同的配置优化，比如apache在配置ContentType的时候可以尽量少支持，尽可能少的LoadModule，保证更高的系统消耗和执行效率。 这一实现起来是比较容易的一现，如果服务器集群 *** 作起来更方便，如果是独立的服务器，新手可能出现上传只能在服务器本地的情况下，可以在令一台服务器设置的IIS采用网络路径来实现服务器，即不用改变程序，又能提高性能，但对于服务器本身的IO处理性能是没有任何的改变。
3、数据库集群和库表散列
大型网站都有复杂的应用，这些应用必须使用数据库，那么在面对大量访问的时候，数据库的瓶颈很快就能显现出来，这时一台数据库将很快无法满足应用，于是需要使用数据库集群或者库表散列。
4、缓存
缓存一词搞技术的都接触过，很多地方用到缓存。网站架构和网站开发中的缓存也是非常重要。架构方面的缓存，对Apache比较熟悉的人都能知道Apache提供了自己的缓存模块，也可以使用外加的Squid模块进行缓存，这两种方式均可以有效的提高Apache的访问响应能力。
网站程序开发方面的缓存，Linux上提供的Memory Cache是常用的缓存接口，可以在web开发中使用，比如用Java开发的时候就可以调用MemoryCache对一些数据进行缓存和通讯共享，一些大型社区使用了这样的架构。另外，在使用web语言开发的时候，各种语言基本都有自己的缓存模块和方法，PHP有Pear的Cache模块，Java就更多了，net不是很熟悉，相信也肯定有。
5、镜像
镜像是大型网站常采用的提高性能和数据安全性的方式，镜像的技术可以解决不同网络接入商和地域带来的用户访问速度差异，比如ChinaNet和EduNet之间的差异就促使了很多网站在教育网内搭建镜像站点，数据进行定时更新或者实时更新。在镜像的细节技术方面，这里不阐述太深，有很多专业的现成的解决架构和产品可选。也有廉价的通过软件实现的思路，比如Linux上的rsync等工具。
6、负载均衡
负载均衡将是大型网站解决高负荷访问和大量并发请求采用的终极解决办法。 负载均衡技术发展了多年，有很多专业的服务提供商和产品可以选择。
硬件四层交换
第四层交换使用第三层和第四层信息包的报头信息，根据应用区间识别业务流，将整个区间段的业务流分配到合适的应用服务器进行处理。 第四层交换功能就象是虚IP，指向物理服务器。它传输的业务服从的协议多种多样，有>你好，具体的请看下面
I/O调度模式：
I/O 即inpu/oupu的缩写，关于数据的读写 *** 作，不同进程请求 数据的优先顺序等等。io调度模式比较复杂，我没有具体测试，这里仅对ray上出现的几个模式做说明，部分参考xda、androidforums、 wik1pedia、linuxarchive资料）
sio
虽然基于deadline，但是它和noop一样，不会对io *** 作进行排序，所以有着noop那样快速的存取速度，但并没有过多优化io *** 作。如果不喜欢noop完全不参与调度，也可以选择这个。
noop
这个调度模式会把所有的数据请求直接合并到一个简单的队列里。不适合有机械结构的存储器，因为没有优化顺序，会增加额外的寻道时间。属于最简单的一个调度模式，无视io *** 作优先级和复杂性，执行完一个再执行一个，如果读写 *** 作繁多的话，就会造成效率降低。
deadline
顾名思义，用过期时间来排序io *** 作顺序，保证先出现的io请求有最短的延迟时间，相对于写 *** 作，给读 *** 作更优先的级别。是比较好的一个调度模式。
cfq
完全公平队列，是anicipaory模式的替代品，没有过多的做预测性调度，而是根据给定的进程io优先级，直接来分配 *** 作的顺序。这个模式在linux上表现良好，但也许并不是最适合android的io调度模式，太强调均衡，而降低了连续读写数据的性能。
vr
具有和deadline相似的 *** 作排序机制，有着最高的峰值读写速度，但是性能比较不稳定，也就是说可能跑出最高的分数，但是也会出现最低值。
Row
顾名思义ROW=Read over we，最大限制减少IO响应时间，并且重排执行 *** 作，直接进行读写 *** 作，给予IO最高优先值。在移动设备中，它将不会在桌面上有 尽可能多的并行线程。通常它是一个单一的线程或最多2个同时工作的线程读写。有利于阅读的请求通过写入读取的延迟大大降低。比deadline好用，但是 如果线程过多有可能会带来瞬间卡顿）
选择你以适合你的就ok；望采纳！
本文将从 Tomcat性能优化，SpringCloud开启重试机制，Zuul网关性能参数优化，Ribbon性能参数优化，Feign与Hystrix性能优化等 五个方面分享在生产环境如何做好SpringCloud性能优化。
一般基于SpringCloud的微服务能够脱离传统的tomcat，独立跑起来，SpringBoot功不可没，其原理是SpringBoot内嵌了tomcat（当然可以换成其他servlet容器，如jetty），能够以java -jar形式就能跑起来。
所以针对每个springboot服务，我们需要对tomcat的一些参数进行优化，以下是楼主项目组优化的tomcat参数配置，供大家参考。
tomcat参数说明：
maxThreads，acceptCount参数应用场景
场景一
场景二
场景三
maxThreads调优
一般说服务器性能要从两个方面说起：
1、cpu计算型指标
2、io密集型指标
所以大部分情况下，tomcat处理io型请求比较多，比如常见的连数据库查询数据进行接口调用。
另外，要考虑tomcat的并发请求量大的情况下，对于服务器系统参数优化，如虚拟机内存设置和linux的open file限制。
maxThreads设置多大合适？
我们知道线程过多，会导致cpu在线程切换时消耗的时间随着线程数量的增加越来越大；线程太少，服务器的请求响应吞吐量会急剧下降，所以maxThreads的配置绝对不是越大越好。
实际情况是设置maxThreads大小没有最优解，要根据具体的服务器配置，实际的应用场景不断的调整和优化。
acceptCount设置多大合适？
尽量与maxThreads的大小保持一致 ， 这个值应该是主要根据应用的访问峰值与平均值来权衡配置的。
当使用URL进行路由时，则需要对zuulhostconnect-timeout-millis和zuulhostsocket-timeout-millis参数控制超时时间。
请求连接的超时时间
请求处理的超时时间
对所有 *** 作请求都进行重试
对当前实例的重试次数，针对同一个服务实例，最大重试次数（不包括首次调用）
对下个实例的重试次数，针同其它的服务实例，最大重试次数（不包括首次server）
注意Hystrix断路器的超时时间需要大于ribbon的超时时间，不然不会触发重试
Feign和Ribbon在整合了Hystrix后，首次调用失败的问题？
目前楼主的强烈做法是： 禁用Hystrix的超时时间，设为false
还有一种是官方提倡的是 设置超时时间。
在实际的项目中亲测，这种方式也有不好的地方， 如请求时间超过5s会出现请求数据时有时无的情况 ，给用户的感觉是 系统不稳定，要求整改 。
另外，禁用hystrix，官方不推荐 。
hystrix超时设置原则
问题：一个> 首先要明确服务器的延迟是什么类型的延迟，以下举几个延迟例子 1例如部署在服务器上的应用，用户访问的时候慢了，感觉有延迟，这个时候需要排查服务器的资源使用情况，IO，CPU，内存使用是否正常，如果资源使用率高达80%以上，就需要考虑优化应用或者扩容了 2服务器的时间延迟，服务器的时间落后于正常的时间，这个时候就需要部署NTP时间同步服务，进行时间同步 3出现网络延迟，服务器的网卡流量打满，导致访问服务器出现网络延迟，这个时候需要排查是什么将网卡流量占用最大，让后进行优化，如果无法优化，则需要进行网卡扩容，或者服务器扩容
2、内存更快， II系列是第四代（其实感觉不到什么差别）
3、存储上，II系列默认就是IO优化了的。I需要单独选IO优化。
如果你购买I的IO优化，最后算下来，买II多花不到什么钱。
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）