建设网站不用模板可以吗,微电影制作,网站制作电话多少钱,大连建设网交费查询目录
一、传统架构#xff1a;简单单体模式
二、分布式架构#xff1a;面向服务架构#xff08;SOA#xff09;
1、服务与SOA
2、SOA战略
3、SOA的两大基石#xff1a;RPC和MQ
三、分布式架构#xff1a;微服务架构#xff08;MSA#xff09;
什么是微服务
微服…目录
一、传统架构简单单体模式
二、分布式架构面向服务架构SOA
1、服务与SOA
2、SOA战略
3、SOA的两大基石RPC和MQ
三、分布式架构微服务架构MSA
什么是微服务
微服务的特点
微服务的优点
微服务的缺点
四、SOA架构和微服务架构的区别和联系
SOA架构特点
微服务架构特点
主要区别 典型的企业级应用系统或者互联网应用系统一般都是通过Web提供一组业务服务能力。这类系统包括提供给用户操作的、运行于浏览器中、具有UI的业务逻辑展示和输入部分运行于服务器端、用后端编程语言构建的业务逻辑处理部分以及用于存储业务数据的关系数据库或其他类型的存储软件。
根据软件系统在运行期的表现风格和部署结构我们可以粗略地将其划分为两大类
整个系统的所有功能单元整体部署到同一个进程所有代码可以打包成1个或多个文件我们可以称之为“单体架构”Monolithic Architecture整个系统的功能单元分散到不同的进程然后由多个进程共同提供不同的业务能力我们称之为“分布式架构”Distributed Architecture
再结合软件系统在整个生命周期的特点我们可以进一步区分不同的架构风格。
对于单体架构我们根据设计期和开发实现期的不同模式和划分结构可以分为
简单单体结构代码层面没有拆分所有的业务逻辑都在一个项目project里打包成一个二进制的编译后文件通过这个文件进行部署并提供业务能力MVC模式系统内每个模块的功能组件按照不同的职责划分为模型Model、视图View、控制器Controller等角色并以此来组织研发实现工作前后端分离模式将前后端代码耦合的设计改为前端逻辑和后端逻辑独立编写实现的处理模式组件模式系统的每一个模块拆分为一个子项目subproject每个模块独立编译打包成一个组件然后所有需要的组件一起再部署到同一个容器里类库模式A系统需要复用B系统的某些功能这时可以直接把B系统的某些组件作为依赖库打包到A系统来使用
对于分布式架构我们根据设计期的架构思想和运行期的不同结构可以分为
面向服务架构Service Oriented ArchitectureSOA以业务服务的角度和服务总线的方式一般是WebService与ESB考虑系统架构和企业IT治理分布式服务架构Distributed Service ArchitectureDSA基于去中心化的分布式服务框架与技术考虑系统架构和服务治理微服务架构MicroServices ArchitectureMSA微服务架构可以看做是面向服务架构和分布式服务架构的拓展使用更细粒度的服务所以叫微服务和一组设计准则来考虑大规模的复杂系统架构设计。
也有人把如上的各个架构风格总结为4个大的架构发展阶段 一、传统架构简单单体模式
简单单体模式是最简单的架构风格所有的代码全都在一个项目中。这样研发团队的任何一个人都可以随时修改任意的一段代码或者增加一些新的代码。开发人员也可以只在自己的电脑上就可以随时开发、调试、测试整个系统的功能。也不需要额外的一些依赖条件和准备步骤我们就可以直接编译打包整个系统代码创建一个可以发布的二进制版本。这种方式对于一个新团队的创立初期需要迅速开始从0到1抓住时机实现产品最短时间推向市场可以省去各种额外的设计直接上手干活争取了时间因而是非常有意义的。
但是这种简单单体模式对于一个系统后期的稳定发展还是有很多坏处的
简单单体模式的系统存在代码严重耦合的问题代码之间的相互引用导致了系统内的对象之间相互依赖关系混乱。修改其中的一处代码可能会引发一大片代码的变化。对于经常需要修改维护的系统很显然会引发很大的问题。简单单体模式的系统变更对部署影响大系统作为一个单体部署每次发布的部署单元就是一个新版本的整个系统系统内的任何业务逻辑调整都会导致整个系统的重新打包部署、停机、再重启进而导致了系统的停机发布时间较长。每次发布上线都是生产系统的重大变更这种部署模式大大提升了系统风险降低了系统的可用性。简单单体模式的系统影响开发效率简单单体模式打包后的部署结构可能过于庞大部署结构过于庞大导致业务系统启动很慢进而也会影响系统的可用性。扩展性受限如果任何一个业务存在性能问题那么都需要考虑多部署几个完整的实例的集群或者再加上负载均衡设备才能保证整个系统的性能可以支撑用户的使用。二、分布式架构面向服务架构SOA
1、服务与SOA
面向服务架构SOA是一种建设企业IT生态系统的架构指导思想。SOA的关注点是服务。服务最基本的业务功能单元由平台中立性的接口契约来定义。通过将业务系统服务化可以将不同模块解耦各种异构系统间可以轻松实现服务调用、消息交换和资源共享。
各个系统的业务拆解为不同粒度和层次的模块和服务服务可以组装到更大的粒度不同来源的服务可以编排到同一个处理流程实现非常复杂的集成场景和更加丰富的业务能力。而且系统的复用可以从以前的代码级的粒度扩展到业务服务的粒度能够快速的对业务和集成需求的变更。SOA从更高的层次对真个系统机型了统一的设计和处理对消息处理和服务调用进行监控优化资源和配置降低系统复杂度和综合成本为业务流程梳理和优化提供技术支撑。
在SOA体系下应用软件被划分为具有不同功能的服务单元并通过标准的软件接口把这些服务联系起来以SOA架构实现的企业应用可以更灵活快速地响应企业业务变化实现新旧软件资产的整合和复用降低软件整体拥有成本。
2、SOA战略
SOA的实施对整个IT生态环境都有重要的影响作为一种重大的IT变革和技术决策必然要自上而下的进行。必须获得管理层的支持由技术决策层面直接推动并和技术部门、相关业务部门一起根据目前各个IT业务系统的现状统一规划SOA战略和分阶段目标制定可行方案与计划步骤逐步推进实施。
3、SOA的两大基石RPC和MQ
SOA关注于系统的服务化不同系统服务间的相互通信就成为了一个重要的话题。并且随着RPC和MQ技术的发展这两种技术逐渐成为SOA的两大基石也是分布式技术体系里的重要基础设施。
RPC
RPC即 Remote Procedure Call远程过程调用是一个计算机通信协议。 该协议允许运行于一台计算机的程序调用另一台计算机的子程序而程序员无需额外地为这个交互作用编程。说得通俗一点就是A计算机提供一个服务B计算机可以像调用本地服务那样调用A计算机的服务。
RPC的调用关系里我们把提供具体的调用方法的系统叫服务提供者Provider调用服务的系统称为服务消费者Consumer。把对象转换为以便于网络传输的二进制或文本数据的过程叫做序列化Serialization二进制或文本数据再还原为对象的过程叫做反序列化Deserialization。 我们可以看到典型的RPC处理机制包括两部分
通信协议可以是基于tcp的也可以是基于http的。数据格式一般是一套序列化反序列化机制。MQ
MQMessage Queue消息队列 异步的远程调用如果能同时存在很多个请求该如何处理呢进一步地由于不能立即拿到处理结果假若需要考虑失败策略重试次数等应该怎么设计呢 如果有N个不同系统相互之间都有RPC调用这时候整个系统环境就是一个很大的网状结构依赖关系有N*(N-1)/2个。任何一个系统出问题都会影响剩下N-1个系统怎么降低这种耦合呢
基于这些问题我们发展出来了消息队列MQ技术所有的处理请求先作为一个消息发送到MQ一般我们叫做broker接着处理消息的系统从MQ拿到消息并进行处理。这样就实现了各个系统间的解耦同时可以把失败策略、重试等作为一个机制对各个应用透明直接在MQ与各调用方的应用接口层面实现即可。 一般来说我们把发送消息的系统称为消息生产者message producer接受处理消息的系统称为消息消费者message consumer。 三、分布式架构微服务架构MSA
什么是微服务 The term Microservice Architecture has sprung up over the last few years to describe a particular way of designing software applications as suites of independently deployable services. While there is no precise definition of this architectural style, there are certain common characteristics around organization around business capability, automated deployment, intelligence in the endpoints, and decentralized control of languages and data. 通过Martin Flowler的这段微服务描述可以抽象出以下几个关键点
由一些独立的服务共同组成应用系统每个服务单独布署、独立跑在自己的进程中每个服务都是独立的业务分布式管理
通过几个关键点可以看出微服务重在独立布署和独立业务而所谓的微服务并不是越小越好而是通过团队规模和业务复杂度由粗到细的划分过程所遵循的原则是松耦合和高内聚。
微服务的特点
单一职责微服务中每一个服务都对应唯一的业务能力做到单一职责微微服务的服务拆分粒度很小例如一个用户管理就可以作为一个服务。每个服务虽小但“五脏俱全”面向服务面向服务是说每个服务都要对外暴露服务接口API。并不关心服务的技术实现做到与平台和语言无关也不限定用什么技术实现只要提供Rest的接口即可自治自治是说服务间互相独立互不干扰团队独立每个服务都是一个独立的开发团队人数不能过多技术独立因为是面向服务提供Rest接口使用什么技术没有别人干涉前后端分离采用前后端分离开发提供统一Rest接口后端不用再为PC、移动段开发不同接口数据库分离每个服务都使用自己的数据源部署独立服务间虽然有调用但要做到服务重启不影响其它服务。有利于持续集成和持续交付。每个服务都是独立的组件可复用可替换降低耦合易维护微服务的优点
1.每个微服务都很小这样能聚焦一个指定的业务功能或业务需求。微服务架构模式给采用单体式编码方式很难实现的功能提供了模块化的解决方案由此单个服务很容易开发、理解和维护。
2.微服务能够被小团队单独开发这个小团队是2到5人的开发人员组成。
3.微服务是松耦合的是有功能意义的服务无论是在开发阶段或部署阶段都是独立的可以加快部署速度。UI团队可以采用AB测试快速的部署变化。微服务架构模式使得持续化部署成为可能
4.微服务能使用不同的语言开发。
5.微服务易于被一个开发人员理解修改和维护这样小团队能够更关注自己的工作成果。无需通过合作才能体现价值。
6.微服务允许你利用融合最新技术。
7.微服务只是业务逻辑的代码不会和HTML,CSS 或其他界面组件混合。 微服务的缺点
1.微服务架构可能带来过多的操作服务拆分
2.需要DevOps技巧
3.可能双倍的努力。
4.分布式系统可能复杂难以管理。开发者需要在RPC或者消息传递之间选择并完成进程间通讯机制。更甚于他们必须写代码来处理消息传递中速度过慢或者不可用等局部失效问题。当然这并不是什么难事但相对于单体式应用中通过语言层级的方法或者进程调用微服务下这种技术显得更复杂一些。
5.因为分布部署跟踪问题难。
6.当服务数量增加管理复杂性增加
7.分区的数据库架构。商业交易中同时给多个业务分主体更新消息很普遍。这种交易对于单体式应用来说很容易因为只有一个数据库。在微服务架构应用中需要更新不同服务所使用的不同的数据库。使用分布式交易并不一定是好的选择不仅仅是因为CAP理论还因为今天高扩展性的NoSQL数据库和消息传递中间件并不支持这一需求。最终你不得不使用一个最终一致性的方法从而对开发者提出了更高的要求和挑战。 四、SOA架构和微服务架构的区别和联系
SOA架构特点
系统集成站在系统的角度解决企业系统间的通信问题把原先散乱、无规划的系统间的网状结构梳理成 规整、可治理的系统间星形结构这一步往往需要引入 一些产品比如 ESB[企业服务总线(Enterprise Service Bus)]、以及技术规范、服务管理规范 这一步解决的核心问题是【有序】系统的服务化站在功能的角度把业务逻辑抽象成 可复用、可组装的服务通过服务的编排实现业务的 快速再生目的把原先固有的业务功能转变为通用 的业务服务实现业务逻辑的快速复用这一步解决 的核心问题是【复用】业务的服务化站在企业的角度把企业职能抽象成 可复用、可组装的服务把原先职能化的企业架构转变为服务化的企业架构进一步提升企业的对外服务能力“前面两步都是从技术层面来解决系统调用、系统功能复用的问题”。第三步则是以业务驱动把一个业务单元封装成一项服务。这一步解决的核心问题是【高效】
微服务架构特点
1.通过服务实现组件化开发者不再需要协调其它服务部署对本服务的影响。2.按业务能力来划分服务和开发团队开发者可以自由选择开发技术提供 API 服务3.去中心化
每个微服务有自己私有的数据库持久化业务数据每个微服务只能访问自己的数据库而不能访问其它服务的数据库某些业务场景下需要在一个事务中更新多个数据库。这种情况也不能直接访问其它微服务的数据库而是通过对于微服务进行操作。数据的去中心化进一步降低了微服务之间的耦合度不同服务可以采用不同的数据库技术SQL、NoSQL等。在复杂的业务场景下如果包含多个微服务通常在客户端或者中间层网关处理。
4.基础设施自动化devops、自动化部署
传统的Java EE部署架构通过展现层打包WARs业务层划分到JARs最后部署为EAR一个大包而微服务则打开了这个黑盒子把应用拆分成为一个一个的单个服务应用Docker技术不依赖任何服务器和数据模型是一个全栈应用可以通过自动化方式独立部署每个服务运行在自己的进程中通过轻量的通讯机制联系经常是基于HTTP资源API这些服务基于业务能力构建能实现集中化管理因为服务太多啦不集中管理就无法DevOps啦。
主要区别 --------------------- 作者devillyd2018 来源CSDN 原文https://blog.csdn.net/devillyd2018/article/details/118032720 版权声明本文为作者原创文章转载请附上博文链接 内容解析ByCSDN,CNBLOG博客文章一键转载插件
