互联网架构发展历程
引言
互联网发展至今，先后经历了单体架构、垂直架构、SOA、最后到了微服务，以及最近比较火爆的server mesh和faas。
1 单体架构
1.1 架构思想
所有的业务模块都集中到一个应用中。最多以war包、甚至整体一个war包，去发布项目。在实际部署中，可以通过分布式共享session来做到水平伸缩。
1.2 优缺点
优点：
- 架构简单、前期成本低，适用于小型项目；
缺点：
- 对于大型项目而言，没有经过业务拆分，团队协作会存在相互掣肘；
- 对于大型项目而言，需要整个项目开发完成，才可以发布。不能持续集成；
- 由于紧耦合，后期功能修改，需要对整个项目进行测试。才可以发布。
2 垂直架构
2.1 架构思想
针对单体架构的问题，在垂直架构中，将系统按高层次的业务做一个划分；然后拆分出一个个子系统；各个子系统按单体架构模式开发。
2.2 优缺点
优点：
- 一定程度地解决了单体架构中各个模块耦合问题；
缺点：
- 业务拆分比较粗狂和暴力，各个子系统存在数据和功能冗余；
- 由于只是简单地划分子系统，所以有很多同步和一致性问题；
- 由于各个子系统依赖紧密，仍然无法满足大型项目的持续交付。
3 SOA
3.1 架构思想
SOA是一种面向服务的架构思想。相对于垂直架构，它强调以服务为单位拆分、做到可复用性。在SOA中，服务是最核心的抽象手段，业务被划分为一些粗粒度的业务服务和业务流程。服务之间的访问通过ESB(企业服务总线)，这样就隔离了服务提供者和服务消费者。所以，SOA只要解决如下问题：
- 信息孤岛
- 互联互通
- 业务重用
- 异构集成
3.2 优缺点
优点：
- 解决了业务复用问题，避免重复工作、提升效率；
- 由ESB负责起各个服务的桥梁，降低了服务之间耦合度，方便独立开发
缺点：
- ESB标准不统一、造成生态不兼容，不利于后期基础设施的技术升级；
- 无论是SCA(ESB是它的一种实现方式)、还是JBI，提倡使用统一的技术平台来解决整个项目问题，不利于特殊子业务做特别的技术选型；
- 各个服务虽然隔离，但是需要与ESB紧耦合。
4 微服务
4.1 架构思想
微服务是对传统SOA的精化，所以有人说：微服务架构 = 80%的SOA服务架构思想 + 100%的组件化架构思想 + 80%的领域建模思想。相对于SOA，微服务强调细粒度拆分、服务自治、去中心化、轻量级API。首先，它要求所以服务以业务为基准进行合理的细粒度拆分；服务拆分决定团队划分，各个团队自己决定自己的技术选型；各个服务不再受ESB牵绊、很独立，服务访问通过服务网关接入、而服务提供者独立于网关；服务对外提供轻量级API，一般以HTTP为载体、restful作为设计标准对外提供服务，因为在各个系统和语言中，HTTP生态支持相对是最健壮的。
4.1.1 设计原则
AKF拆分原则
- 每个服务可以多节点部署，做个集群加负载均衡的模式。即水平扩展；
- 基于业务拆分，做到各个业务自治。即垂直扩展；
- 当用户量暴增的时候，能支持数据分区、分片隔离。即数据分区；
服务自治和资源独享
- 每个服务有自己独立的设计、开发、测试、发布周期；
- 服务上线后，运行、缓存、持久化等资源都是独立的；
Restful通信风格
- API风格以restful为标准。保证简洁、通俗；
前后端分离
- 前端接入层(包括web、app等)之间要相互独立，不能一锅大杂烩；
- 后端只提供标准API，与前端分离。也就是说基础服务不与表示层耦合；
无状态服务
- 需要尽量设计成无状态交付，这样有利于水平部署；
- 如果避免不了会话数据、需要将之迁移到分布式缓存中；
4.2 优缺点
优点：
- 各个业务模块自治。独立技术选型、独立开发、独立测试等，利于持续集成；
- 抛弃ESB的掣肘，更利于后期对某个小模块技术升级；也利于做特别技术选型；
- 对服务细粒度拆分，增加了功能迭代中可复用性；
缺点：
- 服务拆分太细，导致网络中转太多，影响效率；
- 过多服务导致系统运行复杂度高，进而增加了运维复杂度；
- 服务治理与业务耦合；