分布式服务架构和传统的架构区别

 

单一应用架构

　　

　　 优点：网站流量很小，只需要一个应用，就能将所有的功能部署在一起，减少部署节点和成本。

　　　　　 业务简单，开发周期短。

 　　　　　用于简化增删改查工作量的 数据访问框架(ORM) 是关键。

　　缺点：全部功能捆绑在一起，不利于维护和扩展，服务器负载能力有限。

　　　　　代码耦合，开发维护困难,无法针对不同模块进行针对性优化，无法水平扩展单点容错率低，并发能力差

 

负载+垂直架构

优点：系统性能可以扩展，提升负载能力，适合发展中公司的小型项目

　　　当访问量逐渐增大，单一应用增加机器带来的加速度越来越小，将应用拆成互不相干的几个应用，以提升效率。
      此时，用于加速前端页面开发的 Web框架(MVC) 是关键。系统拆分实现了流量分担，解决了并发问题，可以针对不同模块进行优        化，方便水平扩展，负载均衡，容错率提高，系统间相互独立。

缺点：

　　服务之间相互调用，如果某个服务的端口或者ip地址发生改变，调用的系统得手动改变，搭建集群之后，实现负载均衡比较复杂。

　　只能扩展节点服务器，成本高，有瓶颈。

分布式服务架构：

当垂直应用越来越多，应用之间交互不可避免，将核心业务抽取出来，作为独立的服务，逐渐形成稳定的服务中心，使前端应用能更快速的响应多变的市场需求。用于提高业务复用及整合的分布式调用是关键。

优点：

　　将基础服务进行了抽取，系统间相互调用，提高了代码复用和开发效率。

　　对于团队来说，可以更好的分配开发任务

缺点：

　　　貌似只能用于Java