网站建设有些什么流程,我是一条龙怎么停更了,宁波高端网站开发,网站建设需求什么功能文章目录应用层微服务架构服务注册查询 Service Discovery客户端 Service DiscoveryDNS-SD DNS-based Service Discovery服务端 Service Discovery服务注册与注销自注册模式第三方注册模式总结参考应用层
在简单的 3 层结构中#xff0c;Web 服务层既要处理请求#xff0c;又…
文章目录应用层微服务架构服务注册查询 Service Discovery客户端 Service DiscoveryDNS-SD DNS-based Service Discovery服务端 Service Discovery服务注册与注销自注册模式第三方注册模式总结参考应用层
在简单的 3 层结构中Web 服务层既要处理请求又要承载业务功能 而更优的结构是把 Web 层与应用层也叫平台层分开 这样的优势在于
能够单独扩展应用层允许独立加机器、换专用机器复用基础设施简化多端支持缓存、数据库等处理都可以复用使得组织更容易扩展一个团队负责实现/优化平台本身其他多个团队利用平台功能进行开发
分离出应用层之后面临的下一个问题是应用层内部如何划分职责如何协同工作也就是微服务架构所要解决的问题
微服务架构
Monolithic application 架构 把软件应用的不同组件都放到一个程序中就叫 Monolithic application。例如通过编程语言的基本特性将应用划分成类、函数和命名空间用部署流水线来保证变更都经过测试后才部署到生产环境并通过负载均衡机制运行多个实例将其进行横向扩展。 在这种架构模式下应用程序也能很好地工作但存在 2 个问题
变更受限制很小的一处变更也需要对整个应用进行重新构建和部署而且难以控制变更的影响范围不利于扩展无法仅扩展应用中需要更多资源的那些部分只能扩展整个应用 这些限制在云环境下尤其突出。于是微服务架构登上了舞台。 微服务架构提倡把应用程序设计成一系列松耦合的细粒度服务并通过轻量级的通信协议组织起来。 这些服务都能够独立部署、独立扩展每个服务都具有稳固的模块边界甚至允许使用不同的编程语言来编写不同服务也可以由不同的团队来管理。 微服务架构具有下面 9 大特征 1、通过服务进行组件化Componentization via Services 组件可以理解为能够独立更换升级的软件单元一系列组件插在一起构成软件系统。 在微服务架构中组件就是服务通过 Web 服务请求或 RPC 之类的机制通信。这种服务粒度的组件化方式有 2 点优势服务能够独立部署服务具有显式的对外接口
独立部署意味着对一个服务的内部改动只需要重新部署该服务涉及服务接口改动时才需要协同修改多个服务。另一方面还可以通过服务边界和服务协议方面的演进来尽可能减少这样的关联。显式的对外接口则是一种强约束能够保证组件的封装性避免组件间出现过度的紧耦合。但比起进程内调用RPC 的性能成本更高因此 RPC 接口大多是粗粒度的也往往更难使用。另一方面如果想要调整组件职责的话重构成本也更高。 2、围绕业务功能来组织团队Organized around Business Capabilities 微服务允许将系统根据业务功能分解成一系列服务因此可以围绕业务功能来组织跨职能的团队。并且这种组织结构还有利于强化服务边界。比起在 Monolithic application 中按业务线划分团队以服务为边界更清晰、约束力也更强。因为很容易出现跨越模块边界的业务功能而服务边界相对稳固一些。 3、做产品而不是做项目Products not Projects 微服务架构倾向于一个产品由所属开发团队长期维护/演进而不是项目交付后转由另一个维护团队负责。 这种产品理念能够在开发团队与用户之间建立持续的关联让开发团队关注到软件如何帮助用户增进业务功能。 4、智能端点和傻瓜式管道Smart endpoints and dumb pipes 通信机制上一个典型的例子是企业服务总线Enterprise Service Bus消息都流经 ESB由 ESB 负责消息路由、编排、转换以及业务规则的应用随后到达端点endpoints进行处理。这种模式下端点可以保持傻瓜式因为很多逻辑都在 ESB 消息管道里处理了。因此称之为智能管道和傻瓜式端点smart pipes and dumb endpoints。 而微服务倾向于相反的做法智能端点和傻瓜式管道smart endpoints and dumb pipes管道只负责在组件之间分发消息由服务本身针对消息做相应处理。 5、去中心化技术治理Decentralized Governance 中心化技术治理最大的问题在于其局限性统一的技术栈并不一定适用于所有场景。 而在微服务背景下每个服务单独构建就有了选择不同技术栈的机会允许用更合适的工具去做不同的事情。这种技术栈上的自由有助于服务独立演进自然选择出更好的模式。 6、去中心化数据管理Decentralized Data Management 从最抽象的层面看去中心化地管理数据意味着各个系统对客观世界所形成的概念模型各不相同。给模型概念限定一个上下文在该上下文中保证概念严格一致。把一个复杂领域划分成多个界限上下文再将其间关联勾画出来就是概念模型层面的去中心化。具体到数据存储上微服务也进行类似的去中心化策略让每一个服务管理自己的数据库。这些数据库可以是相同数据库的不同实例也可以是完全不同的数据库系统称之为混合持久化。对于去中心化数据存储带来的数据一致性问题可以考虑通过一些补偿操作来让数据最终达到一致。 7、基础设施自动化Infrastructure Automation 与 Monolithic application 相比微服务的部署要更复杂一些。因为在复杂的网络环境中部署多个服务比部署一个独立应用更困难。 8、容错设计Design for failure 在微服务背景下客户端的容错设计更为重要
将服务作为组件使用的一个结果是应用程序需要设计为能够容忍服务故障。
由于供应商不可用任何服务呼叫都可能失败客户必须尽可能优雅地响应。比起 Monolithic application这种容错设计带来的额外复杂性算是一种劣势。另一方面为了快速检测到故障点甚至尽可能自动恢复服务实时监控在微服务架构中也格外重要。 9、演进式设计Evolutionary Design 组件的划分在微服务架构中很关键关系到能否减少变化。一般原则是该组件能否独立更换和升级。 把微服务架构提供的服务分解能力当做一种工具来使用以此实现服务粒度的变化控制
预期一些服务将来会作废不必长期演进把那些会同时变化的东西放到同一个服务中把很少发生变化的部分放到单独服务中与经常发生变化的部分区分开
服务注册查询 Service Discovery
微服务架构下应用被拆分成了多个服务各自运行在不同机器的不同进程中。 如果每个微服务都只运行在单台机器上一个微服务可以通过静态配置表找到其它依赖服务进而通过服务间通信完成协作。然而实际场景下1 个微服务通常会部署在多台机器上并按需动态伸缩增减机器简单的静态配置显然无法满足因而需要一种服务注册查询机制 这点即Service Discovery
客户端 Service Discovery 客户端查询服务注册表得到目标服务的一系列地址并根据负载均衡策略从中选择一个发起请求即客户端负载均衡。 其中服务注册表service registry用来存放所有可用的服务实例并提供管理注册/注销和查询 API
服务注册表是可用服务实例的数据库。
服务注册中心提供了一个管理API和一个查询API。
使用管理API在服务注册表中注册和注销服务实例。
系统组件使用查询API来发现可用的服务实例。具体的在启动服务实例时向注册表添加其网络位置停掉服务时移除记录并在服务实例运行期间通过心跳机制周期性地刷新注册信息。 这种模式相对简单而且客户端能够做出更聪明的比如特定于应用程序的负载均衡决策但也存在一些缺点
客户端用到的每种语言都要实现一遍需要自行维护一个高可用的注册服务服务发现相关逻辑都在客户端实现比如重试造成客户端比较重
DNS-SD DNS-based Service Discovery
特殊的可以将 DNS 用作服务注册表称之为DNS-SDDNS-based Service Discovery 通过 DNS SRV 记录来完成服务到实例的一对多映射
SRV 记录Service locator record通用服务定位记录指定服务所在的服务器域名和端口号多用于 SIPSession Initiation Protocol会话发起协议借助 DNS 虽然简单易操作但受限于 DNS 的更新时效缓存问题
服务端 Service Discovery
当然查询的过程也可以在服务端完成 客户端通过负载均衡器请求目标服务负载均衡器查注册表得到一组可用实例并根据负载均衡策略从中选择一个发起请求。 这种模式下客户端不必再为各种语言、不同框架实现服务查询逻辑简单地向负载均衡器发起请求即可但如果部署平台没有提供这种能力的话需要自行建立并维护这样一个高可用的系统组件。
服务注册与注销
Service Discovery 中服务实例必须注册到服务注册表并及时注销分为自注册与第三方注册 2 种模式。
自注册模式 自注册模式下服务实例负责把自己注册到服务注册表以及从中注销必要的话还要发送心跳请求保持活跃避免其注册过期。这种方式相对简单不依赖其它系统组件但服务实例和服务注册机制产生了耦合以致于注册逻辑需要在各种语言、不同框架的客户端都实现一遍。
第三方注册模式 服务实例不再负责注册/注销交由服务登记员service registrar来处理解除了服务实例与注册机制间的耦合关系。登记员通过轮询部署平台或订阅事件来跟踪服务实例的运行状态发现新服务实例就注册上去发现服务实例停掉了就注销掉。 例如Registrator就采用了这种模式支持自动注册/注销用 Docker 容器部署的服务。
总结
微服务架构负责拆分服务、解耦依赖关系而 Service Discovery 用来解决这些服务间的通信问题让一个微服务能够找到另一个。 实现上分为客户端 Service Discovery 与服务端 Service Discovery 两种区别在于查询/选取逻辑实现在客户端还是服务端。而服务的注册/注销可以由服务自身完成自注册也可以由部署平台等第三方来完成第三方注册
参考
http://www.ayqy.net/blog/service-discovery/
