架构演变过程

当网站流量很小的时候，只需要一个应用，将所有的功能部署在一起，以减少部署节点和成本。缺点：单一的系统架构，使得开发过程中，占有的资源越来越多，可靠性差随着流量的增加难以维护。

解决了单一应用架构所面临的扩容问题(拆分互不相干的几个应用)，流量能够分散到各个子系统中，且系统的体积可控，一定程度上降低了开发人员协同和维护的成本，提升开发效率。缺点：相同逻辑的代码需要不断复制，不能复用，应用直接不能充分解耦。

当垂直应用越来越多，应用之间的交互不可避免，将核心或重复业务抽取出来，作为独立的服务，逐渐形成稳定的共享服务中心。目的是为了系统解耦。

存在问题：如果服务提供方发生改变例如部署的机器由106->107，由于支付及订单缓存列表中用的还是106，需要将其修改为107,或者服务的上线及下线操作，手动配置比较麻烦。服务较多时，管理麻烦，服务治理，容错，发现，IP暴露等都是分布式架构遇到的问题。当服务越来越多、容量的评估、小服务资源的浪费等问题逐渐显现，此时增加一个调度中心基于访问压力实时管理集群容量，提供集群利用率。

SOA：面向服务的架构，是一种设计方法，其中包含了多个服务，服务之间通过相互依赖最终提供一系列功能。服务之间通过良好的接口和契约。

ESB：企业服务总线从SOA发展出来，类似服务中介的概念，主要提供一个服务之间的交互及治理，ESB包含功能：负载均衡，流量控制，加密处理，服务监控等等。

特点：

（1）基于SOA架构思想，将重复公用的功能抽取为组件，以服务的方式向各个系统提供服务

（2）系统与服务之间采用webservice，rpc方式进行通信

（3）ESB企业服务总线作为系统与服务之间的桥梁

优点：

（1）系统与服务之间不直接交互，提高系统的开发效率

（2）可以针对不同的服务的特点进行按需伸缩

（3）ESB可以降低系统之间的耦合度

缺点：

（1）使用了ESB，但是服务之间的协议不固定，种类繁多，不利于系统维护

微服务是基于SOA架构演变出来的，在微服务架构中去除了SOA的架构中ESB消息总线，使用注册中心替代ESB，注册中心相对于ESB更加轻量级，微服务代表技术SpringCloud和Dubbo。

微服务是一种架构风格，一个大型的软件应用，有一个或多个微服务组成，各个服务可以独立部署，各个服务是松耦合的。每个服务专注于一项任务并且很好的完成一项任务。

特点：

服务内部是高内聚，外部是松耦合，高内聚是每个服务只关注一个功能，松耦合是指服务之间没有直接关联。

微服务强调每个服务都是单独数据库，保证每个服务之间不相互影响，选择不同技术平台，去中心化，发挥各种技术平台的特长。

微服务使用Rest API交互，可以自由选择开发技术，更加灵活。

微服务架构 比SOA架构更适合敏捷开发，产品快速迭代。

重点：将业务彻底的组件化和服务化，原有的单个业务系统拆分成多个可以独立开发、设计、运行的小应用，这些小应用通过服务完成交互或集成。

缺点：

运维成本变高，部署模块成倍增加；

分布式系统的更加复杂，通讯成本增加；

分布式系统引出分布式事务的出现有很多解决方案(各有优缺，按照实际的业务选择)；

考虑网络不可靠问题，考虑补偿(Batch或Mq)

当然架构是一步一步演变过来的，流量小时，直接放在一个war中开发，所有功能都集成在一起，所以比较重，不能按照业务进行垂直拆分，但是可以通过使用集群方式扩大一部分流量，但是对系统资源浪费比较验证，例如支付系统流量增减，不能只增加支付系统，后续发展成MVC架构，解决的了开发人员协同开发问题，但是一部分核心重复的功能代码需要在多个War包中不断复制，为了系统解耦，将这些重复的功能抽取成服务，后续来到了分布式架构，分布式架构又给运维管理带了一定的压力，故后续又了微服务架构，注册中心自动发现服务，以前的系统都抽取成了服务，前端可任意扩展，例如pc端，APP端，公众号，后台共用的服务时不变的，而且可以横向扩招，和其他不同业务服务接口，如果需要公共的服务通过RPC或HTTP请求来请求，Dubbo和SpringCloud是实现微服务的两种框架，路易斯.詹姆斯微服务论文中并没有说微服务用什么语言来实现，故微服务和语言没有半毛钱关系，微服务是一种架构风格，指明了其中的通信方式是RestFull风格，不同的业务可以使用各种语言来实现，例如支付系统使用java，大数据系统使用python，当然中间件也可以按照各种中间件的优势及业务场景进行随意组合，当然Dubbo之间的通信使用Netty（NIO）底层使用TCP，Dubbo性能相对于SpingCloud的通讯性能要高，但是(2.7之前)不适合异构系统(跨语言)。但是后续2.7之后支持了rest风格，也可使用在异构系统。当然架构没有好坏只有适合不适合公司的发展，适合公司的架构才是最好的系统