云计算应用系统架构实践三字诀

IaaS本身还是在尽量追求与传统物理环境近乎零差异的运转环境，这无疑给云计算用户带来了很大的好处——切换成本低，甚至无需另行开发。同时，应用能更好地利用云计算达到既定的成本目标、性能目标和运维目标。

总结我们长时间积累的经验和一系列客户迁移的实践，我们发现从传统模式转型到云计算模式下，需要直面一些云计算环境下的问题。

• 云计算环境下数据安全的问题：数据是否有冗余备份、数据是否会被窃取窥视。
• 多用户环境下，网络、CPU、I/O性能隔离问题。
• 云计算必然在物理环境下叠加更多的软件来实现云计算的目标，从而导致软件路径增多，故障率上升的问题。
• 云计算环境下多用户分享所需资源，不存在绝对的顺序I/O。

应用系统想要获得更高的性价比无非就是充分利用云计算的优势、规避云计算的劣势。本文将从运营和研发两个方面提出一些实践建议。

三字秘诀

拆

一般来讲，应用的各模块的核心资源需求如下。

• 应用程序——CPU敏感型。
• Cache——内存敏感型。
• 数据库——I/O敏感型。

如图1左半部分所示，在传统模式下，应用程序、Cache和数据库都安装在一台服务器上，由于应用程序需要高CPU，Cache需要高内存，数据库需要高 I/O，因此IT部门必须买一台“三高”服务器：高CPU、高内存、高I/O。业务稍微有增长，这台服务器就会出现瓶颈，必须再提高配置。

如图1右半部分所示，在利用云计算的情况下，我们通过拆的方法，用不同配置的云主机去匹配专向的需求，用高CPU的云主机去满足应用程序的需求，用16GB 内存的云主机去满足Cache的需求，用SSD硬盘的云主机去满足数据库的需求。当其中某个模块成为瓶颈时，更容易定位问题并及时扩容。

• 弹

由于我们做了第一步拆的工作，架构变得很清晰，所以在资源出现瓶颈时，能迅速扩展相应的模块。如图2所示，当一台应用程序满足不了需求时，我们可以横向扩展2台、3台，甚至更多。

要满足弹的能力，需要注意两个问题：1. 应用程序务必做到无状态，否则无法很快地进行扩容，简单地说，无状态就是不存储任何数据，应用程序做纯粹的逻辑；2. 用Cache的条带化或者合适的Hash算法，来确保内存更大限度地发挥作用。

• 云

在使用“弹”字诀后，很快就会发现，随着业务的增长，数据库在这种模式下将是最大的障碍。这就需要用“云”字诀。

通过将Cache和数据库“云化”来获得云计算对于弹性扩展、容灾、数据备份的支持，解决应用程序中几乎所有的单点问题。

我们提供了UMEM和UDB两个云产品来解决云端Cache和云端DB的问题。数据库的弹性扩展非常值得用一个专题来讨论，这里先简要列举一些方法供参考。

• 将更多的SQL变为KEY/VALUE，在不依赖大于、小于和模糊匹配的情况下，数据扩展更为容易并且性能会得到极大的提升。对于复杂的排序和关系型事物，可通过建立外部独立索引的方式进行实现。
• 在应用程序与DB间引入DBServer对分库分表进行管理，需要应用程序将自己的表结构访问关系梳理清楚。这样，数据库扩容就会成为可能。
• Online Migration。

除了以上3字诀之外，还有一些广泛适应的方法可供参考。

• 动态资源和静态资源的访问分离。
• 静态资源的CDN加速。
• 核心数据和外围数据的访问分离及异步加载。
• 全异步编程，异步网络交互、异步磁盘I/O。
• 减少进程数量，降低CPU的开销。

应用系统运营迁移云计算的建议

• 初始时不要采购过多、过大的机型，因为云计算的扩容时间是以分钟计算的，所以没必要提前花掉不必要的钱。
• 选择一个中立的没有业务竞争关系的云计算供应商，就有希望从源头避免数据私密性的问题。
• 核心数据额外多采用一些备份机制，不要完全信任云计算供应商的方案。
• 多一些小型服务器，优于少数大型服务器，规避单点故障对业务系统的影响。
• 减少非必要的外网IP，从而降低被入侵的风险。
• 善于运用云计算厂商的专业技术人才协助解决一些疑难杂症。
• 规模较大时考虑多家云计算共存的方式规避供应商风险。
• 不要迷信顺序I/O带来的性能优化，在云计算环境下不存在绝对的顺序I/O，利用云计算的存储服务将能更简单地获得想要的效果。

作者莫显峰，Ucloud首席技术官，负责虚拟化、云存储、云网络的研发。曾供职于东软、华为、腾讯，负责海量存储、CDN、云计算平台的研发、运营及管理。

本文为《程序员》原创文章，未经允许不得转载，如需转载请联系market#csdn.net(#换成@)