谈谈对互联网的发展的理解，从熟悉的传统架构项目，到分布式架构项目，再到微服务架构。

1.首先传统的项目是：三层架构

 2.传统架构的问题所在： 

   随着公司发展，业务的俱增，开发人员的增加，传统的开发项目往往会面临这样的问题。开发人员对了以后，人员管理需要花费更多的时间，模块开发沟通需要更多的时间，代码冲突变得越来越多，直接影响开发速度，需要有一套更加合理的架构方案。同时，在性能上，物理机是有抗压上限的，传统的项目是整个项目在一块，然后部署在机器上，将功能模块拆分开，部署在不同的机器上，显然能够突破物理的极限，以满足新的业务需求。

  3.分布式解决传统的问题：

  先说分布式干了什么：分布式是将服务拆分开，将一个系统拆分为若干个子系统，来维护开发，从传统的直接各层调用，变成使用 RPC 技术远程接口的调用，开发团队开始拆分，变成几个人维护一个接口。

  在这里说一下分布式并不是集群，这两个是区分开的概念，不是简单的分别部署在机器上这么简单。集群是来帮助我们解决高并发，高可用的工具。

  4.分布式的优点：代码服务，解耦，适合大的团队开发，解决了传统结构的问题。  

  5. 分布式开发的问题：网络延迟，维护复杂，开发需要解决分布式的问题，比方说分布式事务。因为分布式就是将服务拆开，通过网络调用的方式，去调用接口。 

  6.面向服务架构（我觉得可以理解为分布式）关键性技术：

   走出技术误区，很多人觉得springboot就是微服务，这是不对的，springboot其实做了这样的是，整合了框架，让环境的搭建变得更加方便，比方说使用ssm框架做开发，那么很多依赖需要手动的添加，但是使用了springboot以后，一条依赖就够了，因为springboot帮我们整合好了，集成好了，我们可以借助maven的依赖继承，就可以轻松的把几十条依赖，变成一条依赖，并且不会有依赖冲突问题。springboot 解决的是简化复杂的配置文件的问题。并不能说springboot就是微服务，只是大家都用springboot的轻巧性，来配合做微服务开发。

   关键性技术：前边提到了，将系统拆分开为子系统，这似乎并不需要什么技术，关键就在与拆分开以后的调用上，调用是远程调用的，这就涉及到远程调用技术。远程调用框架有： springCloud    httpClient    hession   dubbo。

   面向服务架构都是基于SOAP通信协议来进行传输的，SOAP协议就是 http协议 + xml 序列化与反序列化操作，这个是比较笨重的，不如json格式的传输跟快。

7.微服务架构：

 微服务架构技术是在SOA上的一个升级，也是分布式架构的一种。那么微服务升级到哪里了呢？它的传输使用的是 http + rest风格 + json。那么微字又体现在哪里呢？体现在拆分的更加细，并且每个服务都是独立运行。

8.面向服务架构和微服务架构的区别：

  面向服务架构主要针对银行，企业 xml格式，企业级ESB服务，就是对安全性要求比较高，这是一种比较重量级的服务，微服务采用http +rest风格 +json 传输更快，是一种轻量级的。