发帖
雷达卡
Java分布式架构设计与开发实战2022全新版莫使金樽空对月
云服务快速入门指南
介绍
微产品团队将继续为您提供微服务快速入云的指导文档，以便开发者和朋友们更好地使用腾讯云微服务产品。内容通俗易懂，使用方便。这是本系列的第一篇文章。欢迎观看。
微服务架构
下图显示了一个典型的微服务架构。从图中可以看出，请求从前端进来后，通常会有一个网关接受所有的请求。该网关通常具有负载均衡功能和一些与流量路由相关的功能。然后网关会把请求转发给后端微服务，然后服务之间的调用会涉及到服务的注册和发现。需要一个注册中心来管理所有的注册和发现，并且需要以一种统一的方式来管理服务的所有配置。此时，还需要一个配置中心来管理所有服务的配置。在服务的过程中，可能需要做熔丝限流、动态路由等操作，这些操作可能会用到服务治理相关的框架或工具来帮助我们完成。同时，在整个过程中，我们需要完善的监测数据来帮助我们排除故障。最后，这些服务调用底层数据库，如MongoDB、MySQL或其他中间件消息队列等。、和上述内容组合成如下所示的典型微服务架构。
应用场景
上述微服务架构下可以使用哪些应用场景？
微服务场景1:搭建一个安全、可靠、强大的业务网关。
典型的Web架构:Nginx网关
典型的基于Nginx的web架构是什么样的？如上图所示，你可以看到网页、小程序、app的请求进来后，会经过一个负载均衡的过程，然后把请求转发给Nginx，Nginx负责把请求转发给后端的web服务，可能是PHP、Tomcat等。这个过程是典型的web架构。
典型的微服务架构:服务网关
典型的微服务架构是什么样的？除了上图所示的Nginx和负载均衡，通常还会有一个服务网关。如图所示，Spring Cloud Gateway将作为服务网关来访问后端服务。服务网关通常会配合服务注册中心做网关直达服务的自动发现，从而实现网关直达服务的需求。
微服务Nginx入口
在另一个场景中，微服务入口模式与K8s合作，在网关级别创建入口控制器，负责从网关直接服务底层服务和K8s控制台的场景。
以上三个是网关级微服务架构下的典型应用场景。除了网关，微服务场景还涉及注册和配置中心。
微服务场景2:构建轻量级、高可用、可扩展的微服务架构。
微服务核心组件=网关+注册中心+配置中心
如上图所示，除了网关之外，我们还将与注册和配置中心合作管理所有的服务实例，并且在此过程中还将涉及监控和链路跟踪的使用，以帮助我们更好地检查业务操作和故障排除。最后，我们将访问底层数据库和一些中间件。这个过程中用到的注册中心的使用场景是怎样的？
注册中心:使用场景
服务和发现
提供者向服务注册后，消费者可以发现服务，服务消费者通过服务注册中心调用提供者。
客户端健康检查
第二个场景是客户端健康检查。如果有100个服务，如何确认这100个服务都正常运行？这时，我们可以使用注册表来实现客户端健康检查。注册中心提供健康检查的能力，并基于心跳报告保持其活动。如果服务器在x秒内没有收到客户端的心跳请求，它会将实例设置为不健康，如果在x秒内没有收到心跳，它会删除临时实例。确保服务的可用性。
内部网DNS访问
最后一种场景是通过注册中心提供DNS访问能力，支持以域名的形式公开注册中心的数据。客户端可以通过域名寻址直接调用直连服务，无需使用CLB转发。
以上是注册中心的几种使用场景。我们来看看配置中心。
配置中心:使用场景
配置中心的使用场景大致可以分为两类。
业务配置
1.第一种情况:在启动新功能时，如果要根据区域用户等信息进行灰度，可以通过配置中心动态管理想要的灰度条件。
2.第二种情况:促销活动的时候，一般会有抽奖，中奖概率，参数控制。我们期望是实时动态控制，这个时候可以通过配置中心来实现。
3.第三种情况:可以通过配置中心动态显示公告。
基本组件配置
例如，在开发过程中，将使用数据库访问键、日志设置或其他组件设置参数。这些参数可以通过配置中心统一管理，不需要修改每个服务，减少工作量。
生产阶段:保证多活动和容灾。
在典型的微服务架构中，它涉及网关注册和配置中心以及服务本身。如何保证整体架构的多产品容灾？然后就会有下面的部署架构。云原生网关和注册与配置中心可以帮助业务架构实现多活动和灾难恢复:
云原生网关的服务器和注册配置中心部署在同一个城市的三个可用区域。
业务应用程序可以部署在同一城市的多个可用区域。一个应用程序的多个节点被部署在不同的可用区域，并在同一服务下注册。
图中红线是可用区域的分界线，上图显示了三个可用区域。为了实现架构的高可用性，有必要确保所使用的每个组件都部署在可用区域中。比如我们的网关会在这三个可用区域部署一个节点，然后我们的服务本身也会跨可用区域部署，在多个可用区域部署不同的节点，所以在注册和配置中心也是一样的。每个注册和配置中心将部署三个节点，然后所有节点将同时跨可用区域部署，以便在实际业务场景中任何一个都可用。
微服务应用场景三:实现全链路的流量和服务治理。
测试阶段:解决多测试环境下的流量路由问题。
如何解决测试环境下的流量路由问题？
从上图我们想解决什么问题？开发者开发微服务时，可能会有多个服务。如果他们想进行联合调试，他们通常会将所有服务部署在一个环境中，然后进行端到端测试。但是，如果有更多的服务，并且开发团队并行工作，就很难协调。
理想的情况是多个测试环境能否以一种方式共存，同时只需要按需部署。那么，不同的团队可以通过使用不同的环境来满足这样的测试需求吗？答案是肯定的，就是用TSE云原生网关加服务治理来实现这种多环境的流量路由。那么做法是怎样的呢？
首先，该示例通过服务治理标记了环境标签。如上图所示，测试环境分为三个环境。第一个是基线环境，这是通常为测试而部署的服务，还有两个特性环境。第一组使用左侧特征环境，第二组使用右侧特征环境。当一个团队想要测试时，只需要将需要测试的服务部署到左边的特性环境中。然后将这些部署的实例标记为feature1，然后在云原生网关触发请求时，将请求标记为feature1，这样这个请求就可以自动路由到我们标记的实例上，实现流量的路由。同时，在路由的过程中，也可以实现跨环境的标签路由。比如我从左边特征环境访问基线环境，然后机器线环境可以根据标签路由返回到这个特征环境，从而实现多测试环境的流量路由问题。
应用场景:微服务应用开发测试时，不需要部署所有服务，只部署本次发生变化的服务，其他服务通过流量动态路由复用基线环境服务资源。
优势:
节约资源成本，按需申请开发/测试，用完后扔掉。
提高R&D效率，摆脱域名本地绑定主机等大量配置工作。
实施方案
1.示例标记
K8s注册场景:向工作负载添加pod标签，以标记环境。
微框架注册场景:服务下的所有实例都是分组的，可以通过标签区分部署环境。
2.流动染色
云原生网关可以染流量特征。例如，染色特定uin的请求。
3.从网关到后端服务的流量路由
通过标签路由，根据请求中的测试环境信息动态路由。
4.后端服务和服务之间的路由
链路上的每个服务可以根据请求流量特征在不同的测试环境中动态地路由服务。
释放阶段:金丝雀，滚动或蓝绿色释放。
在另一种微服务架构下，涉及的问题是发布。
目前比较流行的出版方式有三种，一种是金丝雀出版，一种是滚动出版，一种是蓝绿出版。这三种常见的出版策略都基于相同的原则。他们都期望所有要发布的新版本在发布的过程中都经过绝对的测试，让所有用户避免说我的新版本有任何问题都会影响到所有用户。但是在发布的过程中，这三种发布方式的策略会有些不同。
金丝雀释放
Canary release是按比例升级这个版本，有一定的例子。如果没有问题，那么逐步释放这个比例，直到所有的流量最终达到V2版，从而实现金丝雀。
滚动出版
对于此次发布的服务，首先升级一个/batch实例，然后批量升级其余实例，直到所有实例都升级到V2版本。
蓝色版本
绿色发布就是把实例分成两个阵营，一个绿营，一个蓝营。运行实例的版本是V-1。放在绿营。此时，一个新的实例V2版本被部署到蓝营。然后，对V2版本进行全面测试。测试没问题后，通过负载均衡把流量从V1切到V2，实现了无缝发布，保证了新版本上线环境的全面测试。
发布阶段:全链接灰度
通过以上发布策略，我们可以达到另一个想要的效果，那就是全链接灰度。
全链接灰度是什么意思？比如我们在使用微信的时候，可能会遇到这样的情况，我有一些新功能，别人没有。其实你已经被选为灰度用户，正在测试新功能。只有在灰度环境下测试新功能时，所有用户才会使用该功能。
如何在微服务的框架下达到这种效果？首先，我们需要将部署的实例在生产环境中分为两个环境，一个是正式环境，一个是灰色环境。如果要升级，需要测试要升级的服务的灰度。以前面提到的方式部署新实例后，通过实例标记的方式将其标记为灰度环境中的实例。例如，标记版本是V2。这时候你只需要在请求进来的时候，把网关级别想要灰度的用户的流量染了。例如，将上海的用户标记为V2。那么上海用户的所有流量都会进入灰度环境进行灰度测试。灰度环境测试没有问题。然后所有的业务都会被部署，然后所有的流量都会被切到灰阶环境，这样整个灰阶就实现了。这可以帮助我们实现端到端的环境测试，隔离流量隧道，一键切断流量。
优越性
全链路隔离车道
端到端的稳定环境
一键流切割
可观察性
实施方案
1.示例标记
K8s注册场景:向工作负载添加pod标签来标记版本。
微框架注册场景:服务下的所有实例都是分组的，可以通过标签区分版本。
2.流动染色
用灰度显示网关流量特征。有两种方式:动态染色和静态染色。
3.从网关到后端服务的流量路由
通过标签路由，流量根据请求中的服务版本信息进行转发。
4.后端服务和服务之间的路由
在链路上，每个服务可以根据请求流量特征动态路由。
生产阶段:走访附近，劫后余生。
在生产阶段，微服务的架构有两个重要的场景。第一个是就近参观，第二个是居住和容灾。
最近的访问是什么？一般微服务项目会部署在不同的区域。比如在上海和广州部署一个微服务项目。一个上海的用户想访问这个服务，但是请求被转发到广州，由于地理原因会造成一定的网络延迟。那么我们肯定希望上海的用户访问上海的服务实例，广州的用户访问广州。此时，我们需要使用最近的访问，这有助于我们在地理上标记部署的实例。在实例上标注地理信息，这样当有请求进来的时候，就可以根据这个地理信息找到最近的实例来提供这种就近访问的能力。
多活动容灾分为两个层面，第一个是做入口层面的多活动容灾，第二个是做应用层面的多活动容灾。先说入口层，如下图。我们在网关级别的后端连接不同的可用区域。一旦任何可用区域挂起，网关可以在可用区域之间交换流量，以确保我们的请求不会在网关级别挂起。如果那个城市，比如说广州整个区域挂了，网关可以把这个流量跨城市切换容灾，全部切到上海，这样就保证了请求可以在网关层面无缝切换，保证了我们入口层的多活动容灾。
到了应用层，如下图所示，如果在点中心访问活动中心时，广州1区的活动中心挂机，那么我们可以利用这个服务级别的动态路由能力，将点中心切换到广州2区的活动中心。如果整个广州地区挂机，可以直接把这个请求跨城切换到上海地区，让上海的服务实例响应这样的请求，从而实现应用层的多活和容灾。
优越性
通过云原生网关和北极星服务管理中心，为接入层和应用层提供主动容灾和就近接入。实现故障快速恢复和扩容。
自动获取服务实例的区域信息。
根据区域信息自动进行本地路由
跨区域和跨区域灾难恢复切换
生产阶段:限流场景
限流级:
1.接入层流量限制
2.服务之间的呼叫电流限制
电流限制尺寸:
1.服务/接口/标签的电流限制
2.微服务的当前限制，单位为秒、分、小时、天等。
限流类型:
1.单机电流限制:单个调度实例级别的电流限制。流量限制仅对当前调度的实例有效，不共享。
2.分布式限流:对于服务下的所有实例级限流，多个服务实例共享同一个全局流量限制。
下图是一个关于如何限制入口层和服务之间的流量的简单架构图。
摘要
上面演示中涉及的腾讯云的产品名为微服务引擎TSE，提供开源和增强的云原生网关、注册和配置中心以及服务治理平台，帮助用户快速构建轻量级、高可用、可扩展的微服务架构。微服务引擎完全兼容开源版本，在功能、易用性、可操作性等多方面都有所增强。
上述演示中使用的TSE cloud native gateway将流量网关、安全网关和服务网关结合在一起，实现了统一的网关。具有安全认证、流量保护、流量路由、自定义插件等功能。
弹性微服务的应用场景主要是这些微服务的架构。购物、php应用等容器部署可以放在弹性微服务上，或者为了解决流量峰谷，需要守住流量峰以提高资源利用率，也非常适合使用弹性微服务。
Java分布式架构设计与开发实战2022全新版
download链接：https://pan.baidu.com/s/1xEkD33JmYR53tSKyHT8f3Q?pwd=tjxg
提取码：tjxg
--来自百度网盘超级会员V5的分享
提升卡
置顶卡
沉默卡
变色卡
抢沙发
千斤顶
显身卡
京公网安备 11010802022788号
