襄阳市做网站 优帮云,网站设计预算,不同风格的网页,宣传册设计公司原标题#xff1a;笃学私教#xff1a;Java开发网站架构演变过程-从单体应用到微服务架构详解Java开发网站架构演变过程#xff0c;到目前为止#xff0c;大致分为5个阶段#xff0c;分别为单体架构、集群架构、分布式架构、SOA架构和微服务架构。下面玄武老师来给大家详细…原标题笃学私教Java开发网站架构演变过程-从单体应用到微服务架构详解Java开发网站架构演变过程到目前为止大致分为5个阶段分别为单体架构、集群架构、分布式架构、SOA架构和微服务架构。下面玄武老师来给大家详细介绍下这5种架构模式的发展背景、各自优缺点以及涉及到的一些技术并且教会你如何区分它们。第1阶段单体架构单体架构介绍单体架构就是将所有的应用、数据库、文件都部署在一台机器上俗称All-In-One。简单来讲其实就是我们熟知的SSH架构或SSM架构把所有的业务模块都放在一个应用中开发这里面又衍生出三层架构即表示层、业务逻辑层和数据库访问层虽然在软件设计中划分了经典的三层模型但是对业务场景没有划分一个典型的单体应用就是将所有的业务场景的表示层、业务逻辑层和数据访问层放在一个工程项目中最终经过编译、打包部署在一台服务器上。单体架构图如下单体架构优点1)部署简单: 由于是完整的结构体可以直接部署在一个服务器上即可。2)技术单一: 项目不需要复杂的技术栈往往一套熟悉的技术栈就可以完成开发。3)用人成本低: 单个程序员可以完成业务接口到数据库的整个流程。单体架构缺点1)系统启动慢 一个进程包含了所有的业务逻辑涉及到的启动模块过多导致系统的启动、重启时间周期过长;2)系统错误隔离性差、可用性差任何一个模块的错误均可能造成整个系统的宕机;3)可伸缩性差系统的扩容只能只对这个应用进行扩容不能做到对某个功能点进行扩容;4)线上问题修复周期长任何一个线上问题修复需要对整个应用系统进行全面升级。单体架构向集群架构过渡(1)应用和数据分离随着公司业务的不断发展由于单台服务器性能有限逐渐无法满足业务需求大量用户高并发的访问导致系统性能越来越差数据存储空间开始出现不足这时我们需要将应用和数据分离分离后开始使用三台服务器应用服务器、文件服务器、数据库服务器。如图:应用和数据分离后不同种类的服务器承担着不同的服务角色网站的并发处理能力和数据存储空间都得到了很大的改善支持网站业务进一步发展但是随着用户量进一步增多数据库压力依然越来越大访问延迟不可避免进而影响整个网站的性能糟糕的用户体验使得系统需要进一步优化。单体架构向集群架构过渡(2)缓存的使用随着QPS持续提高为了降低接口访问时间、提高服务性能和并发我们注意到网站访问有个著名的二八定律即80%的业务集中访问在20%的数据上(热数据)其实部分数据有很多不需要每次都从数据库获取比如经常被查询但对准确性要求并不是特别高的数据。如果我们将这一小部分热数据缓存在内存中能够很好的减少数据库的访问压力并大幅提升网站响应速度因此网站就开始加入了缓存应用常用的缓存组件有redisehcache等。注意:能使用缓存的数据得满足如下要求1)对于数据实时性要求不高对于一些经常访问但是很少改变的数据查询明显多于修改适用缓存就很有必要比如一些网站配置项。2)对于性能要求高比如一些秒杀活动场景。第2阶段集群架构缓存在一定程度上解决了数据库访问量比较大的问题但仍无法解决随着业务增多造成的服务器并发压力大的问题因为单台服务器的计算能力有限应用程序运行速度就有限因此这时想要突破服务器性能的瓶颈最直接的办法就是增加一台甚至多台应用服务器来分担原来服务器的访问压力和存储压力多台应用服务器之间没有直接的交互他们都是依赖数据库各自对外提供服务。注意这里的多台应用服务器部署的都是同一套应用程序(即同一套项目源码或war包)这就是集群架构结构如图:思考系统演变到这里将会出现下面四个问题(不做具体展开)1)用户的请求由谁来转发到到具体的应用服务器 2)有什么转发的算法 3)应用服务器如何返回用户的请求 4)用户如果每次访问到的服务器不一样那么如何维护session的一致性 这时候你会发现图中多了一个名为负载均衡器的代理服务器通常我们使用Nginx来实现它的作用主要就是用户不需要记住两个甚至多个应用服务器的IP或域名只要记住一台代理服务器IP就可以了。由代理服务器来负责分发用户是访问哪个应用服务器那么用户具体是访问服务器1、访问服务器2还是服务器N由Nginx里面的权重设置来决定的并且通过Nginx的配置Session共享也可以附带实现保证多台应用服务器的Session一致性。另外这样做还有一个好处就是将代理服务器放在外网应用服务器均放在内网可以有效防止应用服务器被恶意攻击。集群架构演变(1)数据库读写分离系统正常运行了一段时间后虽然加有缓存使绝大多数的数据库操作可以不通过数据库就能完成但是仍然有一部分的数据库操作(缓存访问不命中或缓存过期)和全部的写操作需要访问数据库当用户规模再一步增长后数据库因为负载压力过大还是会成为系统性能的瓶颈这时主流的数据库都提供的有主从热备份功能通过配置两台数据库实现主从关系可以将一台数据库服务器的数据更新同步到另一台服务器上。可以利用这一功能来实现数据库读写分离从而改善数据库的负载压力如图:在图中我们可以发现主数据库服务器负责写操作而从服务器负责读操作这样数据库的压力就被分散在两台服务器上而我们只需保证主从数据库的数据一致性即可这里说明下Mysql的读写分离可以通过自身自带的从主复制实现Oracle数据库可以通过阿里巴巴的mycat组件来实现。概念补充1)负载是指将请求负载到不同的服务器 2)均衡指的是平分服务器的请求次数。 3)热备份指的是它可以在不停止数据库运行的情况下自动的根据定时任务或者数量容量大小去备份数据库。 集群架构演变(2)反向代理和CDN加速为了应对复杂的网络环境和不同地区用户的访问(比如你的服务器在美国或新加坡国内用户直接访问可能会很卡)保障各个地区的用户都能流畅地访问系统可以通过CDN和反向代理来加快用户访问的速度同时减轻后端服务器的负载压力。CDN与反向代理的基本原理其实本质上都是缓存。CDN部署在网络提供商的机房用户请求到来的时候从距离自己最近的网络提供商机房获取数据而反向代理则部署在网站的中心机房中请求带来的时候先去反向代理服务器中查看请求资源如果有则直接返回。结构如图第3阶段分布式架构分布式架构的演变涉及分布式文件、分布式数据库、NoSql、搜索引擎以及业务模块的拆分下面我们一个个看。分布式架构演变(1)分布式文件和分布式数据库即使性能再强大的单台服务器也无法满足大型网站持续增长的业务需求数据库经过读写分离后数据库服务器从一台拆分成了两台但是随着业务的飞速增长依然会达到性能瓶颈这时我们需要使用分布式数据库同时文件系统也一样需要使用分布式文件系统。分布式数据库是数据库拆分的最后的手段只有在表单数据规模非常庞大的时候才使用不到不得已时我们更常用的手段是业务分库将不同的业务数据部署在不同的物理服务器上。结构如图分布式架构演变(2)NoSql和搜索引擎随着业务越来越复杂系统对数据存储和检索的需求也跟着复杂化这时一些NoSQL(Reids,HBase,mongodb)数据库技术和搜索引擎(Solr,Elasticsearch)的时候就显得很有必要。数据库做读库的时候往往对模糊查询显得力不从心即使做了读写分离这个问题还未能解决。以我们电商网站为例发布的商品存储在数据库中用户最常使用的功能就是查找商品尤其是根据商品的标题来查找对应的商品。对于这种需求一般我们都是通过like功能来实现的但是这种方式的代价非常大。此时我们可以使用搜索引擎的倒排索引来完成。搜索引擎能够大大提高查询速度但系统引入搜索引擎后也会带来以下的开销1)带来大量的维护工作我们需要自己实现索引的构建过程设计全量/增加的构建方式来应对非实时与实时的查询需求。2)需要维护搜索引擎集群3)搜索引擎并不能替代数据库他解决了某些场景下的“读”的问题是否引入搜索引擎需要综合考虑整个系统的需求。结构如下图:NoSQL和搜索引擎对可伸缩的分布式特性具有更好的支持应用服务器通过一个统一的数据访问模块访问各种数据减轻应用程序管理诸多数据源的麻烦。分布式架构演变(3)业务模块拆分成子项目当访问量达到一定规模的时候我们可以通过分而治之的手段将整个系统的业务分成不同的产品线例如我们将系统的首页商铺订单买家卖家支付订单等模块拆分成不同的产品线每个产品线都独立成一个子项目每个子项目都有自己的独立的数据库子项目之间通过RPC框架(dubbo,webService,httpClient…)建立连接通信也可以通过消息队列实现异步分发处理从而构成一个完整的系统结构如下图:第4阶段SOA架构SOA是什么SOA全英文是Service-Oriented Architecture意为面向服务编程也称为服务治理是一种思想一种方法论一种分布式的服务架构这里的服务可以理解为service层业务服务它将共同的业务逻辑拆分成独立的应用进行部署这些应用没有视图层只对外提供RPC调用接口。注意区分项目与服务概念项目表达的意思包含业务逻辑层和视图层 服务表达的意思是只包含业务逻辑层没有视图层 SOA 系统原型的一个典型例子是 CORBA它已经出现很长时间其定义的概念与 SOA 相似。SOA 建立在 XML 等新技术的基础上通过使用基于 XML 的语言来描述接口服务已经转到更动态且更灵活的接口系统中CORBA 中的 IDL 无法与之相比。如图描述了一个完整的 SOA 模型。在 SOA 模型中所有的功能都定义成了独立的服务。服务之间通过交互和协调完成业务的整体逻辑。所有的服务通过服务总线或流程管理器来连接。这种松散耦合的架构使得各服务在交互过程中无需考虑双方的内部实现细节以及部署在什么平台上。一个独立的服务基本结构如图所示服务模型的表示层从逻辑层分离出来中间增加了服务对外的接口层。通过服务接口的标准化描述使得服务可以提供给在任何异构平台和任何用户接口使用。这允许并支持基于服务的系统成为松散耦合、面向构件和跨技术实现服务请求者很可能根本不知道服务在哪里运行、是由哪种语言编写的以及消息的传输路径而是只需要提出服务请求然后就会得到答案。举个例子通过上面的图我们可以看出多个子系统直接相互交互相互调用非常凌乱这样我们就很不爽所以我们就用到了我们的SOA架构SOA又叫服务治理SOA就是帮助我们把服务之间调用的乱七八糟的关系给治理起来然后提供一个统一的标准把我们的服务治理成下图所示以前我们的服务是互相交互现在是只对数据总线进行交互这样系统就变得统一起来。各个系统分别根据统一标准向数据总线进行注册各子系统调用其他子系统时我们并不关心如何找到其他子系统我们只找数据总线数据总线再根据统一标准找其他子系统所以数据总线在这里充当一个指路人的作用。SOA的特点1)系统集成站在系统的角度解决企业系统间的通信问 题把原先散乱、无规划的系统间的网状结构梳理成 规整、可治理的系统间星形结构这一步往往需要引入 一些产品比如 ESB、以及技术规范、服务管理规范 这一步解决的核心问题是【有序】2)系统的服务化站在功能的角度把业务逻辑抽象成 可复用、可组装的服务通过服务的编排实现业务的 快速再生目的把原先固有的业务功能转变为通用 的业务服务实现业务逻辑的快速复用这一步解决 的核心问题是【复用】3)业务的服务化站在企业的角度把企业职能抽象成 可复用、可组装的服务把原先职能化的企业架构转变为服务化的企业架构进一步提升企业的对外服务能力“前面两步都是从技术层面来解决系统调用、系统功能复用的问题”。第三步则是以业务驱动把一个业务单元封装成一项服务。这一步解决的核心问题是【高效】SOA的优点1)降低用户成本用户不需要关心各服务之间是什么语言的、不需要知道如果调用他们只要通过统一标准找数据总线就可以了。2)程序之间关系服务简单3)识别哪些程序有问题(挂掉)SOA的缺点提示了系统的复杂程度性能有相应影响。第5阶段微服务架构随着业务拆分越来越小存储系统越来越庞大应用系统的整体复杂度呈指数级增加部署维护越来越困难由于所有应用要和所有数据库系统连接最终导致数据库连接资源不足拒绝服务。1)当服务越来越多时服务URL配置管理变得非常困难F5硬件负载均衡器的单点压力也越来越大。2)当进一步发展服务间依赖关系变得错踪复杂甚至分不清哪个应用要在哪个应用之前启动架构师都不能完整的描述应用的架构关系。3)接着服务的调用量越来越大服务的容量问题就暴露出来这个服务需要多少机器支撑什么时候该加机器4)服务多了沟通成本也开始上升调某个服务失败该找谁服务的参数都有什么约定5)一个服务有多个业务消费者如何确保服务质量6)随着服务的不停升级总有些意想不到的事发生比如cache写错了导致内存溢出故障不可避免每次核心服务一挂影响一大片人心慌慌如何7)控制故障的影响面服务是否可以功能降级或者资源劣化解决方案公共的应用模块被提取出来部署在分布式服务器上供应用服务器调用。也就是我们所说的分布式服务或者微服务。微服务架构是一种架构概念核心思想在于通过将业务功能和需求分解到各个不同的服务中进行管理实现对业务整体解耦。围绕业务模式创建应用服务应用服务可独立地进行开发、迭代、部署使项目的架构更加清晰明确。目前主流的微服务架构框架就是SpringCloud。以下是一个微服务案例的架构图微服务优点1)每个服务足够内聚足够小代码容易理解、开发效率提高2)服务之间可以独立部署微服务架构让持续部署成为可能3)每个服务可以各自进行负载均衡扩展和数据库扩展而且每个服务可以根据自己的需要部署到合适的硬件服务器上4)容易扩大开发团队可以针对每个服务(service)组件开发团队5)提高容错性(fault isolation)一个服务的内存泄露并不会让整个系统瘫痪6)系统不会被长期限制在某个技术栈上。微服务缺点1)开发人员要处理分布式系统的复杂性2)开发人员要设计服务之间的通信机制对于需要多个后端服务的user case要在没有分布式事务的情况下实现代码非常困难3)涉及多个服务直接的自动化测试也具备相当的挑战性4)服务管理的复杂性在生产环境中要管理多个不同的服务的实例这意味着开发团队需要全局统筹(PS现在docker的出现适合解决这个问题)总结架构之间的区别1)单体架构很好区分只要看所有应用程序、文件系统、数据库等是否都在一个服务器上2)集群架构其实就是将原先的单体架构中的应用程序分别部署在多台应用服务器上不过他们还是公用一个数据库。3)分布式架构将原先的单体架构中的项目按照功能模块拆分成多个单独的子项目分别部署在不同的应用服务器并且每个子项目都有自己的独立的数据库。4)SOA架构与微服务架构的区别首先SOA和微服务架构一个层面的东西而对于ESB和微服务网关是一个层面的东西一个谈到是架构风格和方法一个谈的是实现工具或组件。(Service Oriented Architecture)“面向服务的架构”:他是一种设计方法其中包含多个服务 服务之间通过相互依赖最终提供一系列的功能。一个服务 通常以独立的形式存在与操作系统进程中。各个服务之间 通过网络调用。2.微服务架构:其实和 SOA 架构类似,微服务是在 SOA 上做的升华微服务架构强调的一个重点是“业务需要彻底的组件化和服务化”原有的单个业务系统会拆分为多个可以独立开发、设计、运行的小应用。这些小应用之间通过服务完成交互和集成。微服务架构 80%的SOA服务架构思想 100%的组件化架构思想 80%的领域建模思想具体如图返回搜狐查看更多责任编辑
