使用“微服务+云架构”轻松应对系统扩容！

不知道你们打开本文，有没有留意文章所在的分类节点：云计算。其实个人本意，是要将微服务跟云架构归类在一块儿。由于他们都有着一个相同的存在目的：方便扩容！

扩容。对于遇到过系统瓶颈，须要扩容的系统，恭喜你，你的系统必定是快速发展，遇到了访问量上升的状况！

【云架构，系统扩容案例】

先说下我我的的经历：我是作GPS防盗器系统的，硬件须要给后台服务器回发数据，因此硬件产品销售的越好，个人系统就须要面对愈来愈多的压力挑战。感谢经历了这样的一个过程，让我深入意识到了系统扩容架构设计的巨大价值。个人项目里，经历过这么三个阶段：

第一阶段：单机阶段

单机应用，单进程应用，事实证实只能承载几百设备并发。

经过改造多线程，IOCP设计模型，能够承载20000以上的并发

瓶颈点：难以突破单机应用的并发能力，每次遇到难点都得重构。在个人案例里，就是能够增长到30000负载，增长不到50000万负载！

第二阶段：手动拆分多服务器阶段

手动分布式分离设计，网站，socket接收程序，缓存，数据库，使用自建机房独立运行。事实证实，能够承载几十万设备并发

瓶颈点：自建机房防火墙设备有并发数限制，CISCO ASA 5515防火墙最大容许25万链接。

第三阶段：云架构阶段

云架构设计，经过修改系统，实现自动扩容。这个时候，客户端设备数再多也没事，由于阿里云的 复杂均衡SLB以后的ECS服务器数量能够随时添加和减小，目前已经达到了100多万的设备并发链接无压力。

瓶颈点：仅限于我，未来数据库压力还须要进一步优化，可是目前并发设备数上百万毫无压力，不过阿里云的分布式数据库DRDS彷佛也能解决个人难点。

【微服务，模块化应用案例】

个人案例下，重点解释了云架构的做用，没有重点介绍微服务的做用。可是实际上，在几回改造过程当中，已经使用了一点点微服务的功能：

模块化功能，刚才个人案例都是基于总体系统拆分，实际上还有个优化空间就是改形成微服务。“微服务应用”举例：

登陆系统功能：目前同时登录用户最多也就几百人。登录功能代码跟着网站总体发布，负载均衡下须要一会儿维护起来一会儿更新几十台web机器，显然太多余。若是登录功能这个“微服务”组件单独发布，那么只用2台web机器（“登陆功能专用服务器”）专门负载登录功能戳戳有余。未来这部分系统压力增长，只须要增长一台“登录服务器”便可。

查询定位功能：每一个人的定位页面都在高频率刷新访问，虽然只有几百人登录，可是形成的访问次数却高达上万次。怎么办？专门拿出十几台web服务器，用于“定位查询服务器”。这样，若是监控到定位功能有问题，只须要从这十几台“定位查询服务器”中排查问题！

结论：微服务的目的在于软件开发层面的功能化拆分。对于使用微服务：小项目用起来费力，大项目用起来省心。

因此致使如今观点多种：

没接触过大项目的人以为微服务就是个累赘；

接触过大项目的人认可微服务的价值，却不建议小项目使用微服务进行“高射炮打蚊子”

一直作大流量项目的人，提倡使用微服务。

【结论】

微服务的价值：在于未来访问量上升时，精准调控某一个瓶颈点的功能，主要属于开发层面的储备

云架构的价值：在于访问量上升时，直接增长服务器数量扩大系统承载阈值，主要属于运维层面的储备

微服务+云架构：大型系统的重要组合！

原文地址： https://www.opengps.cn/Blog/View.aspx?id=279 文章的更新编辑依此连接为准。欢迎关注源站原创文章！