web1.0
用户只能通过网络获取信息，被动获取信息
web2.0
用户与网络互动，用户与用户互动，淘宝，直播,qq等，数据由用户产生
web3.0
网络开始根据人们数据进行预测，比如导航提示哪里堵车，买商铺提示类似商品
2、技术架构演变
单一架构
优点=方便部署，简单，只需要打一个war包便于测试，便于共享
缺点=不够灵活，维护麻烦，高耦合，可靠性差，技术限制
垂直应用架构
优点：方便水平扩展，负载均衡，架构简单，拆分流量解决并发问题
缺点：相同逻辑功能代码需要不断复制，成本高，容易资源浪费
SOA面向服务架构
优点：将复用的功能抽离出来作为一个单独的模块，提高了代码复用，高可用提高了开发效率
系统与服务的界限模糊，不利于开发和维护
缺点：抽取力度不好把控，容易耦合性过高，部署困难，测试困难
微服务架构
优点：服务拆分更细，利于资源复用，一个新成员也能很快加入模块的开发，每个服务都是一个独立的开发团队
缺点：微服务过多导致治理成本高，不利于系统维护
3、微服务设计原则
AKF拆分原则
前后端分离原则
小公司需要全才，大公司去需要的时术业有专攻，一个人成为全才，反而可能导致没有一个专精的
无服务状态
假设空调与遥控器，假设遥控器与空调都是20度，空调有状态的情况下，遥控器脱离空调范围减一度，再回到空调范围内加一度，此时空调温度是21，空调无状态下，则是20度，无状态的空调状态由遥控器控制
restful风格
基于“无状态通信原则”，在这里我们直接推荐一个实践优选的 Restful 通信风格
，因为他有很多好处：无状态协议 HTTP，具备先天优势，扩展能力很强。例如需要安全加密时，有现成的成熟方案 HTTPS 可用。JSON 报文序列化，轻量简单，人与机器均可读，学习成本低，搜索引擎友好。语言无关，各大热门语言都提供成熟的 Restful API 框架，相对其他的一些 RPC框架生态更完善。
4、CAP 原则与 base 理论
CAP原则
CAP 原则又称 CAP 定理，指的是在一个分布式系统中， Consistency（一致性）、 Availability（可用性）、Partition tolerance（分区容错性），三者不可得兼。CAP 由 Eric Brewer 在 2000 年 PODC 会议上提出。该猜想在提出两年后被证明成立，成为我们熟知的 CAP 定理。CAP 三者不可兼得。
现如今，对于多数大型互联网应用的场景，主机众多、部署分散，而且现在的集群规模越来越大，节点只会越来越多，所以节点故障、网络故障是常态，因此分区容错性也就成为了一个分布式系统必然要面对的问题。那么就只能在 C 和 A 之间进行取舍。但对于传统的项目就可能有所不同，拿银行的转账系统来说，涉及到金钱的对于数据一致性不能做出一丝的让步，C 必须保证，出现网络故障的话，宁可停止服务，可以在 A 和 P 之间做取舍。而互联网非金融项目普遍都是基于 AP 模式。
总而言之，没有最好的策略，好的系统应该是根据业务场景来进行架构设计的，只有适合的才是最好的。
base 理论
最终一致性，base：全称 Basically Available（基本可用），Soft state（软状态），和Eventually consistent（最终一致性）三个短语的缩写，来自 ebay 的架构师提出。既然无法做到强一致性（Strong consistency），但每个应用都可以根据自身的业务特点，采用适当的方式来使系统达到最终一致性（Eventual consistency）
总的来说，base 理论面向的是大型高可用可扩展的分布式系统，和传统事务的ACID 是相反的，它完全不同于 ACID 的强一致性模型，而是通过牺牲强一致性来获得可用性，并允许数据在一段时间是不一致的。
