三废的日常–微服务架构

二废：小废，你们应用架构调整的怎么样了？

小废：目前基本框架已经搭建差不多了。

大废：趁现在没啥事，给我们讲一讲，微服务和分布式有哪些区别，你们做了哪些改进。

小废：好呀，微服务和分布式都是拆分单体应用的产物，但微服务是架构设计方式，而分布式是系统部署方式，很直白地讲，微服务是分布式应用，但分布式应用不一定是微服务。微服务重在解耦合，注重模块划分。分布式重在资源共享，并加快计算速度。

二废：微服务我查过它的几个特点，微服务 称可以实现服务的组件化，开发者专注更高；通过业务能力来划分服务和开发团队，不注重实现方式及开发语言，只对外提供访问接口；去中心化，每个服务都有自己独立的业务数据库，数据去中心化，降低了服务之间的耦合；自动化部署，扩展更加方便。

大废：但微服务真的适合当前的业务场景吗？

小废：俗话说，鞋合不合适，只有脚知道。软件开发没有完美的架构，微服务架构也一样，并不是降低软件系统复杂度的银弹。过度的拆分，不恰当地使用会加大开发运维及测试的负担。目前而言，能切身感受到测试及运维工作的增加。

小废：就目前而言，系统通过业务领域划分，分为几个业务模块的服务，同时由于审批耗时较多，引入消息队列进行异步、消峰、解耦。每个服务都有自己的数据库，做到了业务的解耦。服务之间使用标准化的接口采用REST API来访问，降低了系统之间的依赖和耦合，有利于相互之间的扩展。

小废：到目前为止，应用系统经历了，从单体垂直架构往负载均衡架构、分布式架构、微服务架构的转变，并通过了Nginx软负载系统集群化部署、数据库分库、引入消息队列，我们已经可以让系统架构尽可能用最小的机器资源扛住了最大的请求压力，减轻了数据库的负担。

大废：没错，系统架构的演变，最终目标是要解决不同时刻的瓶颈问题，如数据库访问压力，应用服务器访问压力等。同时，也可以考虑引入缓存集群，数据库分库分表读写分离，来优化架构。对于高写入压力，可以引入消息中间件集群，同时，不要盲目进行数据库扩容，数据库服务器成本昂贵，并且数据库本身就不是用来承载高并发场景的。

小废：还是之前那句话，软件开发没有完美的架构，微服务架构也一样，并不是降低软件系统复杂度的银弹。要根据实际业务情况，来选用适合的架构，才是解决问题的最佳途径。

题外话：本节还是承接上篇，继续架构的演变。至此关于负载均衡、架构的演变已完结。