架构设计思维二阅读总结
上一篇阅读笔记简单说了一下架构设计中分解的问题,这次是说如何将分解完成的各个组件或子系统,通过恰当的方式,最终还可以集成为一个完整的整体,分解是加速开发和降低问题复杂度的便捷方法,如果分解之后无法集成,那么分解就没有意义。因此分解+集成是架构最核心的思考方式和方法。
架构思维中的分解和集成是随着系统的演化进行演化,从单体架构到ESB为代表的SOA架构再到现在流行的微服务。移动互联网出现以后,各种各样的业务:共享单车、支付宝、微信支付等等,业务经历着飞速的变革与创新。
单体架构,Web应用程序发展的早期,在开发服务端企业应用时,应用需要支持各种不同类型的客户端,比如桌面浏览器、移动浏览器以及原生移动应用。应用还需要向第三方提供可访问的API,并通过Web Service或者消息代理与其它应用实现集成。大部分web工程是将所有的功能模块(service side)打包到一起并放在一个web容器中运行,很多企业的Java应用程序打包为war包。应用通过执行业务逻辑、访问数据库、与其它系统交换信息、并返回一条HTML/JSON/XML响应,来处理请求(HTTP请求与消息)。
应用采用多层架构或者六角架构,主要由以下几类不同组件构成:
展现组件——负责处理HTTP请求并响应HTML或者JSON/XML(对于web Services APIs)
业务逻辑——应用的业务逻辑
数据库访问逻辑——用于访问数据库的数据访问对象
不同逻辑组件分别响应应用中的不同功能模块。
SOA架构,SOA架构,是一种粗粒度、开放式、松耦合的服务结构,要求软件产品在开发过程中,按照相关的标准或协议,进行分层开发。通过这种分层设计或架构体系可以使软件产品变得更加弹性和灵活,且尽可能的与第三方软件产品互补兼容,以达到快速扩展,满足或响应市场或客户需求的多样化、多变性。
微服务架构,微服务是一种用于构建应用的架构方案。微服务架构有别于更为传统的单体式方案,可将应用拆分成多个核心功能。每个功能都被称为一项服务,可以单独构建和部署,这意味着各项服务在工作(和出现故障)时不会相互影响。是应用的各项核心功能,而且这些服务均可独立运行。但是,微服务架构不只是应用核心功能间的这种松散耦合,它还涉及重组开发团队、涉及如何进行服务间通信以应对不可避免的故障、满足未来的可扩展性并实现新的功能集成。
集成方式:点对点方式,网关方式,消息代理方式,
在微服务集成过程中,数据服务,事务,查询这些我们需要特别的处理,不像过去的单体架构,基于ESB的SOA架构一样,微服务遇到了之前不存在的问题,现在许多应用一个人无法完成,而且复杂到光靠一个人理解是不可能的,这种情况下,应用就必须拆分成一个个模块,在单体应用中,模块被定义为比方一个java package ,然而这种做法在实践中并不是很理想,时间长了,单体应用就会变得越来越庞大,微服务架构把服务作为一个模块单元,每个服务都有一个不可渗透且很难违反的边界,也就是每个微服务都要提供一种单独而独立的能力
总而言之,架构师每天的工作是不断的做取舍,不断的发掘一个合适的架构思路。架构思维真的很重要!