做一个静态网站需要多少钱,网站建设谈单技巧,设计logo网站是平面设计不,中英文网站源码php戳蓝字“CSDN云计算”关注我们哦#xff01;文章来自#xff1a;Java和Android架构什么是微服务首先微服务并没有一个官方的定义#xff0c;想要直接描述微服务比较困难#xff0c;我们可以通过对比传统WEB应用#xff0c;来理解什么是微服务。传统的WEB应用核心分为业务逻… 戳蓝字“CSDN云计算”关注我们哦文章来自Java和Android架构什么是微服务首先微服务并没有一个官方的定义想要直接描述微服务比较困难我们可以通过对比传统WEB应用来理解什么是微服务。传统的WEB应用核心分为业务逻辑、适配器以及API或通过UI访问的WEB界面。业务逻辑定义业务流程、业务规则以及领域实体。适配器包括数据库访问组件、消息组件以及访问接口等。一个打车软件的架构图如下尽管也是遵循模块化开发但最终它们会打包并部署为单体式应用。例如Java应用程序会被打包成WAR部署在Tomcat或者Jetty上。这种单体应用比较适合于小项目优点是开发简单直接集中式管理基本不会重复开发功能都在本地没有分布式的管理开销和调用开销。当然它的缺点也十分明显特别对于互联网公司来说开发效率低所有的开发在一个项目改代码递交代码相互等待代码冲突不断代码维护难代码功能耦合在一起新人不知道何从下手部署不灵活构建时间长任何小修改必须重新构建整个项目这个过程往往很长稳定性不高一个微不足道的小问题可以导致整个应用挂掉扩展性不够无法满足高并发情况下的业务需求所以现在主流的设计一般会采用微服务架构。其思路不是开发一个巨大的单体式应用而是将应用分解为小的、互相连接的微服务。一个微服务完成某个特定功能比如乘客管理和下单管理等。每个微服务都有自己的业务逻辑和适配器。一些微服务还会提供API接口给其他微服务和应用客户端使用。比如前面描述的系统可被分解为每个业务逻辑都被分解为一个微服务微服务之间通过REST API通信。一些微服务也会向终端用户或客户端开发API接口。但通常情况下这些客户端并不能直接访问后台微服务而是通过API Gateway来传递请求。API Gateway一般负责服务路由、负载均衡、缓存、访问控制和鉴权等任务。微服务架构的优点微服务架构有很多重要的优点。首先它解决了复杂性问题。它将单体应用分解为一组服务。虽然功能总量不变但应用程序已被分解为可管理的模块或服务。这些服务定义了明确的RPC或消息驱动的API边界。微服务架构强化了应用模块化的水平而这通过单体代码库很难实现。因此微服务开发的速度要快很多更容易理解和维护。其次这种体系结构使得每个服务都可以由专注于此服务的团队独立开发。只要符合服务API契约开发人员可以自由选择开发技术。这就意味着开发人员可以采用新技术编写或重构服务由于服务相对较小所以这并不会对整体应用造成太大影响。第三微服务架构可以使每个微服务独立部署。开发人员无需协调对服务升级或更改的部署。这些更改可以在测试通过后立即部署。所以微服务架构也使得CICD成为可能。最后微服务架构使得每个服务都可独立扩展。我们只需定义满足服务部署要求的配置、容量、实例数量等约束条件即可。比如我们可以在EC2计算优化实例上部署CPU密集型服务在EC2内存优化实例上部署内存数据库服务。微服务架构的缺点和挑战实际上并不存在silver bullets微服务架构也会给我们带来新的问题和挑战。其中一个就和它的名字类似微服务强调了服务大小但实际上这并没有一个统一的标准。业务逻辑应该按照什么规则划分为微服务这本身就是一个经验工程。有些开发者主张10-100行代码就应该建立一个微服务。虽然建立小型服务是微服务架构崇尚的但要记住微服务是达到目的的手段而不是目标。微服务的目标是充分分解应用程序以促进敏捷开发和持续集成部署。微服务的另一个主要缺点是微服务的分布式特点带来的复杂性。开发人员需要基于RPC或者消息实现微服务之间的调用和通信而这就使得服务之间的发现、服务调用链的跟踪和质量问题变得的相当棘手。微服务的另一个挑战是分区的数据库体系和分布式事务。更新多个业务实体的业务交易相当普遍。这些类型的事务在单体应用中实现非常简单因为单体应用往往只存在一个数据库。但在微服务架构下不同服务可能拥有不同的数据库。CAP原理的约束使得我们不得不放弃传统的强一致性而转而追求最终一致性这个对开发人员来说是一个挑战。微服务架构对测试也带来了很大的挑战。传统的单体WEB应用只需测试单一的REST API即可而对微服务进行测试需要启动它依赖的所有其他服务。这种复杂性不可低估。微服务的另一大挑战是跨多个服务的更改。比如在传统单体应用中若有A、B、C三个服务需要更改A依赖BB依赖C。我们只需更改相应的模块然后一次性部署即可。但是在微服务架构中我们需要仔细规划和协调每个服务的变更部署。我们需要先更新C然后更新B最后更新A。部署基于微服务的应用也要复杂得多。单体应用可以简单的部署在一组相同的服务器上然后前端使用负载均衡即可。每个应用都有相同的基础服务地址例如数据库和消息队列。而微服务由不同的大量服务构成。每种服务可能拥有自己的配置、应用实例数量以及基础服务地址。这里就需要不同的配置、部署、扩展和监控组件。此外我们还需要服务发现机制以便服务可以发现与其通信的其他服务的地址。因此成功部署微服务应用需要开发人员有更好地部署策略和高度自动化的水平。以上问题和挑战可大体概括为API Gateway服务间调用服务发现服务容错服务部署数据调用幸运的是出现了很多微服务框架可以解决以上问题。第一代微服务框架Spring CloudSpring Cloud为开发者提供了快速构建分布式系统的通用模型的工具包括配置管理、服务发现、熔断器、智能路由、微代理、控制总线、一次性令牌、全局锁、领导选举、分布式会话、集群状态等。 主要项目包括Spring Cloud Config由Git存储库支持的集中式外部配置管理。配置资源直接映射到Spring Environment但是如果需要可以被非Spring应用程序使用。Spring Cloud Netflix与各种Netflix OSS组件EurekaHystrixZuulArchaius等集成。Spring Cloud Bus用于将服务和服务实例与分布式消息传递联系起来的事件总线。用于在集群中传播状态更改例如配置更改事件。Spring Cloud for Cloudfoundry将您的应用程序与Pivotal Cloudfoundry集成。提供服务发现实现还可以轻松实现通过SSO和OAuth 2保护资源还可以创建Cloudfoundry服务代理。Spring Cloud - Cloud Foundry Service Broker提供构建管理一个Cloud Foundry中服务的服务代理的起点。Spring Cloud Cluster领导选举和通用状态模型基于ZooKeeperRedisHazelcastConsul的抽象和实现。Spring Cloud Consul结合Hashicorp Consul的服务发现和配置管理Spring Cloud Security在Zuul代理中为负载平衡的OAuth 2休眠客户端和认证头中继提供支持。Spring Cloud Sleuth适用于Spring Cloud应用程序的分布式跟踪与ZipkinHTrace和基于日志例如ELK跟踪兼容。Spring Cloud Data Flow针对现代运行时的可组合微服务应用程序的云本地编排服务。易于使用的DSL拖放式GUI和REST-API一起简化了基于微服务的数据管道的整体编排。Spring Cloud Stream轻量级事件驱动的微服务框架可快速构建可连接到外部系统的应用程序。使用Apache Kafka或RabbitMQ在Spring Boot应用程序之间发送和接收消息的简单声明式模型。Spring Cloud Stream Application StartersSpring Cloud任务应用程序启动器是Spring Boot应用程序可能是任何进程包括不会永远运行的Spring Batch作业并且它们在有限时间的数据处理之后结束/停止。Spring Cloud ZooKeeperZooKeeper的服务发现和配置管理。Spring Cloud for Amazon Web Services轻松集成托管的Amazon的Web Services服务。它通过使用Spring的idioms和APIs便捷集成AWS服务例如缓存或消息API。开发人员可以围绕托管服务不必关心基础架构来构建应用。Spring Cloud Connectors使PaaS应用程序在各种平台上轻松连接到后端服务如数据库和消息代理以前称为“Spring Cloud”的项目。Spring Cloud Starters作为基于Spring Boot的启动项目降低依赖管理在Angel.SR2后不在作为独立项目。Spring Cloud CLI插件支持基于Groovy预言快速创建Spring Cloud的组件应用。DubboDubbo是一个阿里巴巴开源出来的一个分布式服务框架致力于提供高性能和透明化的RPC远程服务调用方案以及SOA服务治理方案。其核心部分包含远程通讯 提供对多种基于长连接的NIO框架抽象封装包括多种线程模型序列化以及“请求-响应”模式的信息交换方式。集群容错提供基于接口方法的透明远程过程调用包括多协议支持以及软负载均衡失败容错地址路由动态配置等集群支持。自动发现基于注册中心目录服务使服务消费方能动态的查找服务提供方使地址透明使服务提供方可以平滑增加或减少机器。但是显而易见无论是Dubbo还是Spring Cloud都只适用于特定的应用场景和开发环境它们的设计目的并不是为了支持通用性和多语言性。并且它们只是Dev层的框架缺少DevOps的整体解决方案这正是微服务架构需要关注的。而随之而来的便是Service Mesh的兴起。下一代微服务Service MeshService MeshService Mesh又译作“服务网格”作为服务间通信的基础设施层。如果用一句话来解释什么是Service Mesh可以将它比作是应用程序或者说微服务间的TCP/IP负责服务之间的网络调用、限流、熔断和监控。对于编写应用程序来说一般无须关心TCP/IP这一层比如通过 HTTP 协议的 RESTful 应用同样使用Service Mesh也就无须关系服务之间的那些原来是通过应用程序或者其他框架实现的事情比如Spring Cloud、OSS现在只要交给Service Mesh就可以了。Service Mesh有如下几个特点应用程序间通讯的中间层轻量级网络代理应用程序无感知解耦应用程序的重试/超时、监控、追踪和服务发现Service Mesh的架构如下图所示Service Mesh作为Sidebar运行对应用程序来说是透明所有应用程序间的流量都会通过它所以对应用程序流量的控制都可以在Service Mesh中实现。目前流行的Service Mesh开源软件有Linkerd、Envoy和Istio而最近Buoyant开源Linkerd的公司又发布了基于Kubernetes的Service Mesh开源项目Conduit。LinkerdLinkerd是开源网络代理设计为以服务网格部署用于管理控制和监控应用程序内的服务与服务间通讯的专用层。Linkerd旨在解决Twitter、Yahoo、Google和Microsoft等公司运营大型生产系统时发现的问题。根据经验最复杂令人惊奇和紧急行为的来源通常不是服务本身而是服务之间的通讯。Linkerd解决了这些问题不仅仅是控制通讯机制而是在其上提供一个抽象层。它的主要特性有负载平衡Linkerd提供了多种负载均衡算法它们使用实时性能指标来分配负载并减少整个应用程序的尾部延迟。熔断Linkerd包含自动熔断将停止将流量发送到被认为不健康的实例从而使他们有机会恢复并避免连锁反应故障。服务发现Linkerd 与各种服务发现后端集成通过删除特定的(ad-hoc)服务发现实现来帮助您降低代码的复杂性。动态请求路由Linkerd 启用动态请求路由和重新路由允许您使用最少量的配置来设置分段服务staging service金丝雀canaries蓝绿部署blue-green deploy跨DC故障切换和黑暗流量dark traffic。重试次数和截止日期Linkerd可以在某些故障时自动重试请求并且可以在指定的时间段之后让请求超时。TLSLinkerd可以配置为使用TLS发送和接收请求您可以使用它来加密跨主机边界的通信而不用修改现有的应用程序代码。HTTP代理集成Linkerd可以作为HTTP代理几乎所有现代HTTP客户端都广泛支持使其易于集成到现有应用程序中。透明代理您可以在主机上使用iptables规则设置通过Linkerd的透明代理。gRPCLinkerd支持HTTP/2和TLS允许它路由gRPC请求支持高级RPC机制如双向流流程控制和结构化数据负载。分布式跟踪Linkerd支持分布式跟踪和度量仪器可以提供跨越所有服务的统一的可观察性。仪器仪表Linkerd支持分布式跟踪和度量仪器可以提供跨越所有服务的统一的可观察性。EnvoyEnvoy是一个面向服务架构的L7代理和通信总线而设计的这个项目诞生是出于以下目标对于应用程序而言网络应该是透明的当发生网络和应用程序故障时能够很容易定位出问题的根源。Envoy可提供以下特性外置进程架构可与任何语言开发的应用一起工作可快速升级。基于新C11编码能够提供高效的性能。L3/L4过滤器核心是一个L3/L4网络代理能够作为一个可编程过滤器实现不同TCP代理任务插入到主服务当中。通过编写过滤器来支持各种任务如原始TCP代理、HTTP代理、TLS客户端证书身份验证等。HTTP L7过滤器支持一个额外的HTTP L7过滤层。HTTP过滤器作为一个插件插入到HTTP链接管理子系统中从而执行不同的任务如缓冲速率限制路由/转发嗅探Amazon的DynamoDB等等。支持HTTP/2在HTTP模式下支持HTTP/1.1、HTTP/2并且支持HTTP/1.1、HTTP/2双向代理。这意味着HTTP/1.1和HTTP/2在客户机和目标服务器的任何组合都可以桥接。HTTP L7路由在HTTP模式下运行时支持根据content type、runtime values等基于path的路由和重定向。可用于服务的前端边缘代理。支持gRPCgRPC是一个来自谷歌的RPC框架使用HTTP/2作为底层的多路传输。HTTP/2承载的gRPC请求和应答都可以使用Envoy的路由和LB能力。支持MongoDB L7支持获取统计和连接记录等信息。支持DynamoDB L7支持获取统计和连接等信息。服务发现支持多种服务发现方法包括异步DNS解析和通过REST请求服务发现服务。健康检查含有一个健康检查子系统可以对上游服务集群进行主动的健康检查。也支持被动健康检查。高级LB包括自动重试、断路器全局限速阻隔请求异常检测。未来还计划支持请求速率控制。前端代理可作为前端代理包括TLS、HTTP/1.1、HTTP/2以及HTTP L7路由。极好的可观察性对所有子系统提供了可靠的统计能力。目前支持statsd以及兼容的统计库。还可以通过管理端口查看统计信息还支持 第三方的分布式跟踪机制。动态配置提供分层的动态配置API用户可以使用这些API构建复杂的集中管理部署。IstioIstio是一个用来连接、管理和保护微服务的开放平台。Istio提供一种简单的方式来建立已部署服务网络具备负载均衡、服务间认证、监控等功能而不需要改动任何服务代码。想要为服务增加对Istio的支持您只需要在环境中部署一个特殊的边车sidecar使用Istio控制面板功能配置和管理代理拦截微服务之间的所有网络通信。Istio目前仅支持在Kubernetes上的服务部署但未来版本中将支持其他环境。Istio提供了一个完整的解决方案通过为整个服务网格提供行为洞察和操作控制来满足微服务应用程序的多样化需求。它在服务网络中统一提供了许多关键功能流量管理控制服务之间的流量和API调用的流向使得调用更可靠并使网络在恶劣情况下更加健壮。可观察性了解服务之间的依赖关系以及它们之间流量的本质和流向从而提供快速识别问题的能力。策略执行将组织策略应用于服务之间的互动确保访问策略得以执行资源在消费者之间良好分配。策略的更改是通过配置网格而不是修改应用程序代码。服务身份和安全为网格中的服务提供可验证身份并提供保护服务流量的能力使其可以在不同可信度的网络上流转。Istio服务网格逻辑上分为数据面板和控制面板数据面板由一组智能代理Envoy组成代理部署为边车调解和控制微服务之间所有的网络通信。控制面板负责管理和配置代理来路由流量以及在运行时执行策略。下图显示了构成每个面板的不同组件ConduitConduit是为Kubernetes设计的一个超轻型服务网格服务它可透明地管理在Kubernetes上运行的服务的运行时通信使得它们更安全可靠。Conduit提供了可见性、可靠性和安全性的功能而无需更改代码。Conduit service mesh也是由数据面板和控制面板组成。数据面板承载应用实际的网络流量。控制面板驱动数据面板并对外提供北向接口。对比Linkerd和Envoy比较相似都是一种面向服务通信的网络代理均可实现诸如服务发现、请求路由、负载均衡等功能。它们的设计目标就是为了解决服务之间的通信问题使得应用对服务通信无感知这也是Service Mesh的核心理念。Linkerd和Envoy像是分布式的Sidebar多个类似Linkerd和Envoy的proxy互相连接就组成了service mesh。而Istio则是站在了一个更高的角度它将Service Mesh分为了Data Plane和Control Plane。Data Plane负责微服务间的所有网络通信而Control Plane负责管理Data Plane Proxy并且Istio天生的支持Kubernetes这也弥合了应用调度框架与Service Mesh之间的空隙。关于Conduit的资料较少从官方介绍看它的定位和功能与Istio类似。Kubernetes Service Mesh 完整的微服务框架Kubernetes已经成为了容器调度编排的事实标准而容器正好可以作为微服务的最小工作单元从而发挥微服务架构的最大优势。所以我认为未来微服务架构会围绕Kubernetes展开。而Istio和Conduit这类Service Mesh天生就是为了Kubernetes设计它们的出现补足了Kubernetes在微服务间服务通讯上的短板。虽然Dubbo、Spring Cloud等都是成熟的微服务框架但是它们或多或少都会和具体语言或应用场景绑定并只解决了微服务Dev层面的问题。若想解决Ops问题它们还需和诸如Cloud Foundry、Mesos、Docker Swarm或Kubernetes这类资源调度框架做结合但是这种结合又由于初始设计和生态有很多适用性问题需要解决。Kubernetes则不同它本身就是一个和开发语言无关的、通用的容器管理平台它可以支持运行云原生和传统的容器化应用。并且它覆盖了微服务的Dev和Ops阶段结合Service Mesh它可以为用户提供完整端到端的微服务体验。所以我认为未来的微服务架构和技术栈可能是如下形式多云平台为微服务提供了资源能力计算、存储和网络等容器作为最小工作单元被Kubernetes调度和编排Service Mesh管理微服务的服务通信最后通过API Gateway向外暴露微服务的业务接口。我相信未来随着以Kubernetes和Service Mesh为标准的微服务框架的盛行将大大降低微服务实施的成本最终为微服务落地以及大规模使用提供坚实的基础和保障。推荐阅读2018全球50大最佳发明名单程序员崩溃了想拿的年终奖怎么说黄就黄资源 | 最新版区块链术语表中英文对照程序员有话说 | 程序猿在乘地铁的时候都在想什么?清华北大“世界排名断崖式下跌”SparkAlluxio性能调优十大技巧从云计算到AINetApp的数据网络转型之道1.微信群添加小编微信color_ld备注“进群姓名公司职位”即可加入【云计算学习交流群】和志同道合的朋友们共同打卡学习2.征稿投稿邮箱liudancsdn.net微信号color_ld。请备注投稿姓名公司职位。喜欢就点击“好看”吧
