传统单体架构
经典3层模型
- 表现层:交互层,用于直接与用户交互。通常指网页,UI
- 业务逻辑层:业务逻辑处理层
- 数据访问层:用于操作数据库
经典的单体架构
- 表现层、逻辑层、数据访问层在一个工程,编译打包,部署在一台服务上。
- 经典的J2EE工程:表现层JSP、业务逻辑层Service Controller和数据访问层Dao ,打成war包,部署在tomcat等其他的servlet容器中运行。
- 经典的部署方式LMAP
单体架构优势
- 开发快速
- 运维难度低、系统管理方便
- 服务器成本低
单体架构不足
- 不停迭代,代码量冗余,可读性、可维护性和可扩展性下降。
- 单体应用并发能力有限
- 单一系统,并行困难,不利于告诉迭代
单体架构服务器集群
- 负载均衡:处理高并发网络请求,将访问分派到不同的应用服务器。软负载:nginx等,硬负载:F5等
- 应用部署集群:横向扩展,高可用。用户量增加,扩展服务器即可。
- 缓存服务器:提高响应速度,缓解数据库压力。
- 数据库:主从备,读写分离 ; 分库分表
单体架构服务器集群的不足
- 单体应用,代码量依旧冗余,可读性、可维护性、可扩展性还是欠缺。
- 海量访问,数据库依旧是瓶颈。
- 单应用依旧迭代缓慢,持续交付能力差
由此可见,在应用初期,单体应用从成本、开发时间和运维方面有优势。但随着业务量和用户量增加,缺点也显而易见
微服务
什么是微服务
- MicroServices
- 微服务最初是由Martin Fowler提出来的他的理解如下:
微服务架构就是将单一程序开发成一个微服务,每个微服务运行在自己的进程中,并使用轻量级的机制通信,通常是HTTP RESTFUL API。这些服务围绕业务能力来划分,并通过自动化部署机制来独立部署。这些服务可以使用不同的编程语言,不同数据库,以保证最低限度的集中式管理。 - 特点:
- 服务单元:按业务划分独立的运行程序
- HTTP协议互相通信
- 自动化部署
- 支持不同语言,不同存储技术
- 服务集中化管理
- 分布式系统
- 熔断机制
微服务的优势
- 复杂业务拆分小业务,每个业务拆分一个服务,服务边界明确;简单化,代码可读性和可扩展性好
- 服务与服务之间耦合度低,随着业务的增加,可以再拆分服务,具有极强的横向扩展能力。
- 服务间通过HTTP协议通信,支持新老系统的交互,支持异语言,异架构的系统交互
- 服务切分后各自直接高度解耦合,单服务重构简单,新人学习成本降低,上手简单
- 微服务独立部署,对并行修改、迭代,方便快速持续交付
- 微服务在CAP理论中采用AP架构,具有高可用和分区容错的特定。
微服务的不足
- 微服务的技术复杂度:涉及较多的微服务技术,构建一个微服务系统远比单提系统复杂,有一定的学习成本
- 分布式事务:每个服务都是独立的单元,CAP理论中,分布式是AP架构,所以数据强一致性需要做额外的处理
- 两阶段提交,事务协调器
- 业务逻辑补偿
- 服务的划分
- 服务的部署和管理
- 服务的治理,监控和管理;大量的配置。服务的启停顺序
- 基于云服务器,Docker编排(微服务最佳部署容器),DevOps(部署手段或理念);
微服务应具备的功能
- 服务的注册和发现
- 服务的负载均衡
- 服务的容错
- 服务网关
- 服务的统一配置管理
- 链路追踪
- 实时日志
微服务和SOA的关系
- SOA:中心化
- 面向服务的架构,往往与企业服务总线(ESB)联系在一起。
- 实施思路是根据ESB模式集成大量单一庞大系统的落地方式。
- 微服务:去中心化
- 组件化,敏捷化
- 点对点