web架构之所以会持续演进，个人认为主要是两方面的驱动因素，一是解决“三高”问题，二是新技术的快速发展。
而总体的演进思路无非就是各种拆分（分层、分割、分布式、集群、异步、缓存），最终利用硬件平滑的弹性扩展，构建终极架构形态。所以接下来就从拆分和分布式的思路描述企业级应用架构的演进过程。对于搜索引擎技术、缓存技术、内存数据库技术、应用容器化等技术的卓越贡献，在本篇文章就不细致描述了。
1.应用与数据库物理资源的拆分
从web应用与本地数据库部署在一台服务器，演进为二者分开部署。在提高系统负载能力的同时，也提高了容灾能力，更可歌可泣的是，此方式也为今后的架构演进提供了基本思路：“增加硬件服务器是个行之有效的办法”。
2.应用服务器分布式集群
将应用服务器从一台变为多台，这样用户请求的负载压力被均衡分配。此种方式的优化效果很好理解，但要解决很多问题才能真正实现负载均衡，①如何实现用户请求平均分配。②如何实现用户请求的调度转发。③如何实现服务器故障切换。④如何实现session一致性。
3.数据库读写分离
大多数应用对于数据库的压力都集中在各种各样、各个维度、各种查询条件组合的查询与统计操作，不过把数据库一分为二，显然不是最终形态，他同样存在很多问题，①如何实现主从库的数据同步问题。②数据操作对于数据源的选择问题。③仅仅一分为二很难彻底缓解数据“读”库的压力。
4.数据库水平拆分与垂直拆分
对数据库读写分离一分为二显然很容易达到瓶颈，而对读库的水平拆分，则充分的解决了数据查询的负载问题。而数据库的垂直拆分，其实不能在当前的演进阶段就草率执行，这里要引进企业中台的感念，个人认为，业务中台是数据中台的驱动，数据中台是业务中台的基础，也就是说，要想对数据做垂直拆分，不仅要对业务做拆分，还要对业务本身的服务做边界清晰的拆分，才能保证数据垂直拆分的可行性。数据库拆分同样带来一些问题，①依然是数据源路由问题。②垂直拆分后主外键设置问题。③垮库数据操作的jion问题。④夸业务库的事务问题。
5.数据库分表分库
就是大表变小表，阿里对于分表的建议是3年内单表数据量超过5000万条，分表同样带来很多问题，①同一张表拆分后的关联查询。②事务操作变的异常复杂。③数据维护成本极高。④横向扩容的hash取模问题。⑤结果集的合并和排序问题。
6.微应用、微服务拆分
为什么要把微应用、微服务放在一起说，个人认为微应用适用范围有限且是一个过渡阶段，单纯的应用拆分虽然运维升级较为简单，但存在太多的公共模块或者说公共代码，如果功能模块升级改造，会导致所有的引用模块共同升级，这也是微服务逐步发展的最大契机。基于业务边界对服务进行合理拆分，应用于服务通过HTTP、PRC等方式调用，假设不考虑其它问题，这样的架构模式，基本是企业web架构的终极形态了，至少已拆无可拆，相关技术也趋于成熟，比如Dubbo、SpringCloud等框架都不同程度的实现了服务治理、限流、熔断、降级、自动化运维的功能，然而不同的接口访问方式不同，包括接口形式、数据格式、编码格式等等差异化问题，导致企业内部应用服务集成都变得极为复杂，何况外部集成。因此引用了企业服务总线ESB，引用了消息中间件。然而ESB存在一些显而易见的问题，①增加设计开发成本。②对于建设中或者运行中的应用或服务很不友好。③增加硬件资源与运维成本。④容易出现“雪崩”效应。去中心化虽能彻底解决问题，可谈何容易，最终还得扯到企业信息化管理成熟度上去，哈哈。
