1、web应用架构的发展历程
现代网络架构由最开始的单体架构渐渐演变:
- 单体架构(MVC)
单体架构中,所有的代码都是写在JSP里面。一个典型的单体架构就是一个应用、一个数据库、一个web容器。(如下图)
一般在在企业发展的初期,为了保证快速上线,或者传统企业中垂直度较高,访问压力较小的业务需求会采用这种架构风格。最初这种单体架构开发,开发速度快,成本低,但随着业务的发展,逻辑越来越复杂,代码量越来越大,代码得可读性和可维护性越来越低。用户的增加,访问量越来越多,单体架构的应用并发能力十分有限。
- 垂直架构(MVC架构模式)
在单体架构发展一段时间后,为了应对更大的流量,将系统进行MVC分层,每个层级有对应的职责,UI层负责和用户进行交互、业务逻辑层负责具体的业务功能、数据库层负责和数据库进行数据交换和存储。如下图
- SOA(Service-Oriented Architectur)
SOA即面向服务架构,它是一套松耦合的架构,服务的拆分原则是:服务内部高内聚,服务之间低耦合。将系统根据不同的职责划分为不同的模块,不同的模块直接通过特定的协议和接口进行交互。这样使整个系统切分成很多单个服务组件来完成请求,当流量过大时通过水平扩展相应的组件来支撑,所有的组件通过交互来满足整体的业务需求。
SOA服务化的优点是,它可以根据需求通过网络对松散耦合的粗粒度应用组件进行分布式部署、组合和使用。服务层是SOA的基础,可以直接被应用调用,从而有效控制系统中与软件代理交互的人为依赖性。
2、什么是微服务
基于SOA(面向服务开发的架构),渐渐产生了微服务架构,微服务可以说是SOA的一种升华,它更加强调服务个体的独立性、拆分粒度更小。微服务的架构的就是将项目拆分成各个子项目,进行解耦操作,提供外部访问接口。比如:把淘宝网订单系统,商品系统,购物车系统,账户系统,支付系统等等分成一个个不同的子项目,每一个子项目就是一个微服务。
微服务优点:
- 微服务架构强调业务系统需要彻底的组件化和服务化,将复杂的业务拆分成多个小的业务,一个组件就是一个服务。
- 微服务系统是分布式系统,业务与业务之间完全解耦,随着业务的增加可以根据业务再拆分,具有极强的横向扩展能力。面对搞并发的场景可以将服务集群化部署,加强系统负载能力。
- 服务间采用HTTP协议通信,服务与服务之间完全独立。
- 微服务不再强调传统SOA架构里面比较重的ESB企业服务总线
- 微服务强调每个微服务都有自己独立的运行空间,包括数据库资源。
- 微服务的切分粒度会更小
微服务带来的问题:
- 分布式系统的复杂性:
系统应用由原来的单体变成几十到几百个不同的工程,会所产生例如包括服务间的依赖,服务如何拆封,内部接口规范,数据传递等等问题,尤其是服务拆分,需要团队熟悉业务流程,懂得取舍,要保证拆分的粒度服务既符合“高内聚,低耦合”的基本原则,还要兼顾业务的发展。
- 部署,测试和监控的成本问题
对于分布式系统,部署,测试和监控都需要大量的中间件来支撑,而且中间件本身也要维护。
- 分布式事务和CAP的相关问题
原先单体应用很简单的事务问题 ,转到分布式环境就变得很复杂,分布式事务是采用简单的重试+补偿机制,还是采用二阶段提交协议等强一致性方法来解决,就要取决对业务场景的熟悉加上反复的权衡了,相同问题还包括对 CAP 模型的权衡,总之微服务对团队整体的技术栈水平整体要求更高。