公司网站模板,上海黄页固定电话查询,为企业做网站赚钱吗,襄阳seo优化服务本文涉及的内容以及知识点如下#xff1a; 1、单体架构 2、单体架构的拆分 3、SOA与微服务的区别 4、微服务的优缺点 5、微服务的消息 6、服务集成 7、数据的去中心化 单体架构 Web应用程序发展的早期#xff0c;大部分web工程是将所有的功能模块#xff08;service… 本文涉及的内容以及知识点如下 1、单体架构 2、单体架构的拆分 3、SOA与微服务的区别 4、微服务的优缺点 5、微服务的消息 6、服务集成 7、数据的去中心化 单体架构 Web应用程序发展的早期大部分web工程是将所有的功能模块service side打包到一起并放在一个web容器中运行很多企业的Java应用程序打包为war包。其他语言RubyPython或者C写的程序也有类似的问题。 假设你正在构建一个在线商店系统客户下订单、核对清单和信用卡额度并将货物运输给客户。很快你们团队一定能构造出如下图所示的系统。 这种将所有功能都部署在一个web容器中运行的系统就叫做单体架构也叫巨石型应用。 单体架构有很多好处IDE都是为开发单个应用设计的、容易测试——在本地就可以启动完整的系统、容易部署——直接打包为一个完整的包拷贝到web容器的某个目录下即可运行。 但是上述的好处是有条件的应用不那么复杂。对于大规模的复杂应用单体架构应用会显得特别笨重要修改一个地方就要将整个应用全部部署PS在不同的场景下优势也变成了劣势;编译时间过长;回归测试周期过长;开发效率降低等。另外单体架构不利于更新技术框架除非你愿意将系统全部重写代价太高你愿意老板也不愿意。 单体架构的拆分 详细一个网站在业务大规模爬升时会发生什么事情?并发度不够?OK加web服务器。数据库压力过大?OK买更大更贵的数据库。数据库太贵了?将一个表的数据分开存储俗称“分库分表”。这些都没有问题good job。不过老外的抽象能力比我们强看下图Fig2。 这张图从三个维度概括了一个系统的扩展过程 1x轴水平复制即在负载均衡服务器后增加多个web服务器; 2z轴扩展是对数据库的扩展即分库分表分库是将关系紧密的表放在一台数据库服务器上分表是因为一张表的数据太多需要将一张表的数据通过hash放在不同的数据库服务器上; 3y轴扩展是功能分解将不同职能的模块分成不同的服务。从y轴这个方向扩展才能将巨型应用分解为一组不同的服务例如订单管理中心、客户信息管理中心、商品管理中心等等。 SOA与微服务 SOA:服务导向式架构SOA是集成多个较大组件一般是应用的一种机制它们将整体构成一个彼此协作的套件。一般来说每个组件会从始至终执行一块完整的业务逻辑通常包括完成整体大action所需的各种具体任务与功能。组件一般都是松耦合的但这并非SOA架构模式的要求。 微服务是一种架构设计模式。 在微服务架构中业务逻辑被拆分成一系列小而松散耦合的分布式组件共同构成了较大的应用。每个组件都被称为微服务而每个微服务都在整体架构中执行着单独的任务或负责单独的功能。每个微服务可能会被一个或多个其他微服务调用以执行较大应用需要完成的具体任务系统还为任务执行——比如搜索或显示图片任务或者其他可能需要多次执行的任务提供了统一的解决处理方式并限制应用内不同地方生成或维护相同功能的多个版本。 1. 负责单个功能 2. 单独部署 3. 包含一个或多个进程 4. 拥有自己的数据存储 5. 一支小团队就能维护几个微服务 6. 可替换的 相对于SOA区别如下 SOA尝试将应用集成一般采用中央管理模式来确保各应用能够交互运作。微服务尝试部署新功能快速有效地扩展开发团队。它着重于分散管理、代码再利用与自动化执行。 微服务的优缺点 微服务架构模式有很多好处。 第一通过分解巨大单体应用为多个服务方法解决了复杂性问题。 在功能不变的情况下应用被分解为多个可管理的分支或服务。每个服务都有一个用 RPC- 或者消息驱动 API 定义清楚的边界。 第二这种架构使得每个服务都可以有专门开发团队来开发。 开发者可以自由选择开发技术提供 API 服务。 第三微服务架构模式使得每个微服务独立部署开发者不再需要协调其它服务部署对本服务的影响。 最后微服务架构模式使得每个服务独立扩展。你可以根据每个服务的规模来部署满足需求的实利。 微服务架构也有不足。其中一个跟他的名字类似“微服务”强调了服务大小实际上有一些开发者鼓吹建立稍微大一些的10-100 LOC服务组。尽管小服务更乐于被采用但是不要忘了微服务只是结果而不是最终目的。微服务的目的是有效的拆分应用实现敏捷开发和部署。 另外一个不足之处在于微服务应用是分布式系统由此会带来固有的复杂性。开发者需要在 RPC 或者消息传递之间选择并完成进程间通讯机制。此外他们必须写代码来处理消息传递中速度过慢或者不可用等局部失效问题。 另外一个关于微服务的挑战来自于分区的数据库架构。同时更新多个业务主体的事务很普遍。这种事务对于单体式应用来说很容易因为只有一个数据库。在微服务架构应用中需要更新不同服务所使用的不同的数据库。 测试一个基于微服务架构的应用也是很复杂的任务。另外一个挑战在于微服务架构模式应用的改变将会波及多个服务。部署一个微服务应用也很复杂一个单体应用只需要在复杂均衡器后面部署各自的服务器就好了。每个应用实例是需要配置诸如数据库和消息中间件等基础服务。每个服务都有多个实例这就形成大量需要配置、部署、扩展和监控的部分。除此之外你还需要完成一个服务发现机制后续文章中发表以用来发现与它通讯服务的地址包括服务器地址和端口 微服务消息 1同步消息 – REST, Thrift 同步消息就是客户端需要保持等待直到服务器返回应答。REST是微服务中默认的同步消息方式它提供了基于HTTP协议和资源API风格的简单消息格式多数微服务都采用这种方式每个功能代表了一个资源和对应的操作。 Thrift是另外一个可选的方案。它采用接口描述语言定义并创建服务支持可扩展的跨语言服务开发所包含的代码生成引擎可以在多种语言中如 C, Java, Python, PHP, Ruby, Erlang, Perl, Haskell, C#, Cocoa, Smalltalk 等创建高效的、无缝的服务其传输数据采用二进制格式相对 XML 和 JSON 体积更小对于高并发、大数据量和多语言的环境更有优势。 2异步消息 – AMQP, STOMP, MQTT 异步消息就是客户端不需要一直等待服务应答有应到后会得到通知。某些微服务需要用到异步消息一般采用AMQP, STOMP, MQTT。 3消息格式 – JSON, XML, Thrift, ProtoBuf, Avro 消息格式是微服务中另外一个很重要的因素。SOA的web服务一般采用文本消息基于复杂的消息格式SOAP和消息定义xsd。微服务采用简单的文本协议JSON和XML基于HTTP的资源API风格。如果需要二进制通过用到Thrift, ProtoBuf, Avro。 4服务约定 – 定义接口 – Swagger, RAML, Thrift IDL 如果把功能实现为服务并发布需要定义一套约定。单体架构中SOA采用WSDLWSDL过于复杂并且和SOAP紧耦合不适合微服务。 REST设计的微服务通常采用Swagger和RAML定义约定。 对于不是基于REST设计的微服务比如Thrift通常采用IDLInterface Definition Languages比如Thrift IDL。 服务集成 SOA体系下服务之间通过企业服务总线Enterprise Service Bus通信许多业务逻辑在中间层消息的路由、转换和组织。 微服务架构倾向于降低中心消息总线类似于ESB的依赖将业务逻辑分布在每个具体的服务终端。 大部分微服务基于HTTP、JSON这样的标准协议集成不同标准和格式变的不再重要。另外一个选择是采用轻量级的消息总线或者网关有路由功能没有复杂的业务逻辑。下面就介绍几种常见的架构方式。 1、点对点方式 – 直接调用服务 点对点方式中服务之间直接用。每个微服务都开放REST API并且调用其它微服务的接口。 图通过点对点方式通信 很明显在比较简单的微服务应用场景下这种方式还可行随着应用复杂度的提升会变得越来越不可维护。这点有些类似SOA的ESB尽量不采用点对点的集成方式。 2、API-网关方式 API网关方式的核心要点是所有的客户端和消费端都通过统一的网关接入微服务在网关层处理所有的非业务功能个。通常网关也是提供REST/HTTP的访问API。服务端通过API-GW注册和管理服务。 图通过API-网关暴露微服务 用我们网上商店的例子在图5中所有的业务接口通过API网关暴露是所有客户端接口的唯一入口。微服务之间的通信也通过API网关。 采用网关方式有如下优势 a.有能力为微服务接口提供网关层次的抽象。比如微服务的接口可以各种各样在网关层可以对外暴露统一的规范接口。 b.轻量的消息路由、格式转换。 c.统一控制安全、监控、限流等非业务功能。 d.每个微服务会变得更加轻量非业务功能个都在网关层统一处理微服务只需要关注业务逻辑 目前API网关方式应该是微服务架构中应用最广泛的设计模式。 3、消息代理方式 微服务也可以集成在异步的场景下通过队列和订阅主题实现消息的发布和订阅。一个微服务可以是消息的发布者把消息通过异步的方式发送到队列或者订阅主题下。作为消费者的微服务可以从队列或者主题共获取消息。通过消息中间件把服务之间的直接调用解耦。 图异步通信方式 通常异步的生产者/消费者模式通过AMQP、MQTT等异步消息规范。 数据去中心化 单体架构中不同功能的服务模块都把数据存储在某个中心数据库中。 图单体架构用一个数据库存储所有数据 微服务方式多个服务之间的设计相互独立数据也应该相互独立比如某个微服务的数据库结构定义方式改变可能会中断其它服务。因此每个微服务都应该有自己的数据库。 图每个微服务有自己私有的数据库其它微服务不能直接访问。 数据去中心话的核心要点 1、每个微服务有自己私有的数据库持久化业务数据 2、每个微服务只能访问自己的数据库而不能访问其它服务的数据库 3、某些业务场景下需要在一个事务中更新多个数据库。这种情况也不能直接访问其它微服务的数据库而是通过对于微服务进行操作。 数据的去中心化进一步降低了微服务之间的耦合度不同服务可以采用不同的数据库技术SQL、NoSQL等。在复杂的业务场景下如果包含多个微服务通常在客户端或者中间层网关处理。 写在最后提及架构没有绝对最好的架构只有最适合业务的架构。技术架构应该从业务中来到业务中去其抽象于业务而高于业务。作为技术开发的我们不能一味的追求架构而架构我们必须在公司业务发展团队资源中间做一个合适的选择然后随着业务的发展逐步重构与优化。 你可能也喜欢: 阿里P8架构师谈主流RPC框架详解以及与SOA、SOAP、REST的区别阿里P8架构师谈Zookeeper的原理和架构设计以及应用场景 阿里P8架构师谈Spring Cloud与Dubbo的详细比较阿里P8架构师谈微服务Dubbo和SpringCloud架构设计、优劣势比较 阿里P8架构师谈Restful、SOAP、RPC、SOA、微服务之间的区别 微服务系列服务注册与发现的实现原理、及实现优劣势比较
