为什么要用分布式架构，又为什么要用微服务？

上次面试时经常被问到一个问题，你为什么要用dubbo？

由于经验尚浅，实在是没说得明明白白。

我用了dubbo后，我就可以这样调接口，巴拉巴拉，说到底还是争不过面试官问：那照你这么说，我不用分布式架构也可以完成啊，你只是说了用了分布式架构后业务处理的方法，并没有弄懂里面的原因。

结果自然是。。。。。。。给了offer，没去

简要的分析一下单体架构的优缺点，再说说用了分布式架构后会遇到的问题吧。

单体架构：

   ——优点：

1、易于开发：开发的方式简单，方便运行也容易调试。

2、易于测试。

3、易于部署。

 优点显而易见~

 ——缺点：

1、项目过于臃肿，维护成本大，出现bug难定位。

2、资源无法隔离：共享一个数据库，或者一块内存。

如果一个功能模块突然访问量过大，可能影响整个系统的性能。

3、无法灵活扩展：单体系统也可以集群部署，但是不够灵活，我明明只是订单系统遇到了瓶颈，

只需要将订单模块水平扩展就行，但现在要将整个系统水平扩展。不灵活！

4、交付周期长：所有功能得一起上线，一起构建，一起部署。

任何一个环节出错，都可能影响交付。

那分布式的优点自然就和单体架构就对立了~

再谈谈分布式架构的缺点：

1、性能，分布式系统是跨进程，跨网络的，性能很收网络延迟和带宽的影响。

2、可靠性：由于高度依赖网络状况，任何一次远程调用都可以失败。

随着服务的增多，还会出现更多的潜在故障点。

3、异步：引入各种中间件，异步通信大大增加了功能实现的复杂度。

4、数据一致性：分布式系统必然会有分布式事务的出现，这时对数据的一致性，

需要在C（一致性）A（可用性）P（分区容错性）中做出选择。

5、运维成本：一个系统拆成了多个服务，每个服务都得配置，部署，监控，日志处理。

得到的同时也意味着失去，权衡与取舍 始终是架构的魅力