共计 1403 个字符，预计需要花费 4 分钟才能阅读完成。
不知道大家打开本文，有没有留意文章所在的分类节点：云计算。其实我的本意，是要将微服务跟云架构归类在一起。因为他们都有着一个相同的存在目的：方便扩容！
扩容。对于遇到过系统瓶颈，需要扩容的系统，恭喜你，你的系统一定是快速发展，遇到了访问量上升的情况！
【云架构，系统扩容案例】
先说下我个人的经历：我是做 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 文章的更新编辑依此链接为准。欢迎关注源站原创文章！
