3月17日-19日，由CSDN重磅打造的互联网运维开发实战峰会、数据库核心技术与应用实战峰会和互联网应用架构实战峰会在上海举行。 三场峰会邀请了业内顶尖的架构师和技术专家，共同探讨运维、数据库和架构领域的话题与技术。
网易云首席解决方案架构师刘超受邀在第一天的互联网运维开发实战峰会上发表了演讲，分享了人们理解和使用云计算的误区，以及云原生应用设计的正确方式。很多人以为虚拟化了就算是云平台，把应用移到虚拟机和云主机甚至是容器上就算完成了上云。但是从应用层面来说，所有影响灵活和弹性能力的设计都会阻碍云计算潜力的发挥。
云计算的庞氏骗局？
刘超首先向在座的开发和运维人员提出了以下几个问题：
从云计算诞生以来，我们经历了物理机，虚拟机，OpenStack和Docker等技术：
- 物理机稳定，性能好，仅需要Linux的知识就可以运维。但是隔离性不够好，资源使用率也不够高；
- 于是，传统的虚拟化应用而生，但是传统虚拟化的成本比较高，不仅License很贵，相关的技术人员招聘也很难；
- 大部分厂商显然并不会想被这种传统虚拟化长期绑定，于是诞生了开源的实现技术OpenStack。OpenStack开源无绑定、兼容性强。但是开源的软件并不稳定，要实现商业化必然要进行定制，反而从一个绑定切换到另一个绑定。而且大多数采用OpenStack技术的公司，最终都会发现运维团队并没有减少，需要招聘的技术人员也会有更高的要求；
- 接下来Docker的横空出世又给云计算带来了新的曙光，Docker轻量级，易迁移，能够实现DevOps和持续集成/持续交付。Docker看起来很简单，但实际上是将复杂性转移给了平台层。应用要运行起来，需要安装和配置的一样都不能省。要实现Docker在生产级别的应用，底层配备的基础设施的复杂度不亚于OpenStack。
云计算使用的误区
之所以会出现这些问题，刘超认为大部分人，还是在用传统的思路使用云计算，应用还没有云化。刘超总结了云计算使用的八大误区：
1.传统单体应用不加修改，就进行虚拟机或容器的部署。这样做的问题是打包的东西太多，应用配置起来非常复杂，无法实现横向扩展，更有甚者一台物理机里只跑一个容器，完全没有享受到容器带来的好处。
2.不想修改应用，而期望虚拟化层的技术改进，达到“既想马儿跑又想马儿不吃草”的效果。比如希望虚拟机或容器能够达到物理机的性能，虽然Intel等厂商在硬件层面针对虚拟化做了很多改进，但会大大降低应用的可迁移性和灵活性。所以云计算的用户首先要意识到，虚拟化必然会造成性能损耗，应该通过应用的改造，去利用云计算的横向扩展能力，从而抵销这种性能损耗。
- 期望对虚拟机进行细粒度的调度，感知物理机和机架。传统的运维通常会问为什么云计算不能提供迁移的功能，把应用从一个机器迁移到另一个机器，或者把应用分布在不同的物理机甚至机架上。实际上还是把云计算当成传统的物理机来用。如下图所示，左边是Nova的架构，中间是Kubernetes的架构，他们在设计之初就提供了schedule的机制，如果用户非要去感知底层的硬件，其实是在重复造轮子。
全公司共用一个账号，这个账号由运维控制，所有的操作都要通过他的批准。实际上每一个云计算平台都是有账号和子账号的管理体系的，云计算的弹性就是为了实现自运维，而不是需要层层审批的传统方式。
不规划和使用VPC进行隔离，隔离性上有很大的问题。
所有的机器都带公网IP地址，并且使用用户名密码登录，这些做法都会为系统带来安全隐患。
期望完全由基础设施层解决应用层的高可用问题。比如内存的数据或硬盘的缓存，哪个重要哪个不重要，哪些数据坚决不能丢，这些都是你的应用才知道的，云平台并不能区分。
- 自己搭建数据库、大数据平台等公共基础设施。这会大大增加公司的运维成本，而实际上每个公有云平台都提供了相应的PaaS平台来提供这些服务。
总结起来就是，基础设施层、平台层、应用层，每一层都应该各司其职，不要把责任压给另外一层。特别是应用层的设计，要考虑到这个应用未来是运行在云上的，要提供能实现弹性扩展和容灾备份的机制，一般这种机制被称为云原生（Cloud Native）。
云原生应用设计要点
从基础设施这一层来说，网易云从虚拟机到容器，将OpenStack和Docker做了很好的融合，比如容器运行在虚拟机上，使用IaaS层的能力解决网络和存储的问题，避免了容器产生的网络和存储性能损耗。刘超从安全隔离、高性能、容器集群和日志监控等角度进行了详细说明：
那么应用架构层，用户应该如何设计才能实现云原生应用呢？刘超总结了8个设计要点：
1.负载均衡+API网关。在线上运维的区域中，对外连通公网的部分，最好通过云平台提供的负载均衡，因为大多数云服务商的负载均衡功能中，都附加了DDoS防御和WAF的功能；
2.服务拆分和服务发现。
3.使用PaaS服务降低设计难度。下图是网易考拉用到的网易云平台的PaaS服务。
4.无状态化服务的改造。主要就是把内存中的数据保存到缓存中，把用户数据保存到数据库中，把文件保存到分布式存储中，这样应用中只包含商务逻辑，无论怎么扩展都只是商务逻辑的扩展，下面的存储也都有自己的集群，不需要应用层做过多的考虑。
5.容器作为持续集成/持续交付的工具。有些人会把容器作为虚拟机来用，但容器的优势更多体现在它的标准化和准确的版本控制，从而形成一套非常顺畅的DevOps流程。
6.基于代码仓库的持续交付流程，将所有的手工操作代码化，每个运行起来的环境都应该对应一个代码的分支，所有的修改都要基于这些分支，对镜像进行修改，触发持续集成的流程。
- 集中的配置管理。配置也应该保存在代码中，集中下发。
- 基于流和搜索引擎的日志分析。
综上所述，基础架构层应该做到足够的弹性，和一定程度的调优，但不要做太多影响扩展性的调优；应用层应该向云原生发展，实现更好的弹性伸缩和持续集成/持续交付的流程，这样两者合作起来，才能有效地降低运维成本。
