新网站推广最直接的方法企业网站推广服务

新网站推广最直接的方法,企业网站推广服务,营销的四种方式,做微网站的公司为什么要用Istio 微服务搞到一定规模#xff0c;总会遇到这些问题#xff1a; 服务间调用怎么做负载均衡#xff1f;怎么实现灰度发布#xff1f;服务挂了怎么自动熔断#xff1f;调用链怎么追踪#xff1f;服务间通信怎么加密#xff1f; 这些东西如果每个服务自己实现…为什么要用Istio微服务搞到一定规模总会遇到这些问题服务间调用怎么做负载均衡怎么实现灰度发布服务挂了怎么自动熔断调用链怎么追踪服务间通信怎么加密这些东西如果每个服务自己实现代码里会塞满各种SDK和框架升级维护都是噩梦。Istio的思路是把这些通用能力下沉到基础设施层。每个Pod边上部署一个Sidecar代理Envoy所有进出流量都经过它。服务代码不用改流量治理、可观测性、安全策略都在Sidecar里搞定。部署Istio环境要求Kubernetes 1.25kubectl配置好集群至少4核8GIstio组件本身吃资源安装用istioctl安装最方便# 下载istioctlcurl-L https://istio.io/downloadIstio|sh-cdistio-1.20.0exportPATH$PWD/bin:$PATH# 安装demo配置生产环境用productionistioctlinstall--setprofiledemo -y# 验证kubectl get pods -n istio-system输出应该有这些组件NAME READY STATUS istiod-5f4f9b8d4d-xxxxx 1/1 Running istio-ingressgateway-7b9d5f8d8-xxxxx 1/1 Running istio-egressgateway-7f9b8f8d8d-xxxxx 1/1 Running启用自动注入给命名空间打标签新建的Pod会自动注入Sidecarkubectl label namespace default istio-injectionenabled# 验证kubectl get namespace -L istio-injection流量管理基础部署示例应用先部署两个版本的服务# reviews-v1.yamlapiVersion:apps/v1kind:Deploymentmetadata:name:reviews-v1spec:replicas:2selector:matchLabels:app:reviewsversion:v1template:metadata:labels:app:reviewsversion:v1spec:containers:-name:reviewsimage:docker.io/istio/examples-bookinfo-reviews-v1:1.18.0ports:-containerPort:9080---apiVersion:apps/v1kind:Deploymentmetadata:name:reviews-v2spec:replicas:2selector:matchLabels:app:reviewsversion:v2template:metadata:labels:app:reviewsversion:v2spec:containers:-name:reviewsimage:docker.io/istio/examples-bookinfo-reviews-v2:1.18.0ports:-containerPort:9080---apiVersion:v1kind:Servicemetadata:name:reviewsspec:ports:-port:9080name:httpselector:app:reviewsVirtualService流量路由VirtualService定义流量怎么走apiVersion:networking.istio.io/v1beta1kind:VirtualServicemetadata:name:reviewsspec:hosts:-reviewshttp:-match:-headers:end-user:exact:jasonroute:-destination:host:reviewssubset:v2-route:-destination:host:reviewssubset:v1这个配置的意思如果请求头有end-user: jason走v2版本其他请求走v1版本DestinationRule定义子集apiVersion:networking.istio.io/v1beta1kind:DestinationRulemetadata:name:reviewsspec:host:reviewssubsets:-name:v1labels:version:v1-name:v2labels:version:v2trafficPolicy:connectionPool:tcp:maxConnections:100http:h2UpgradePolicy:UPGRADEhttp1MaxPendingRequests:100http2MaxRequests:1000实战灰度发布灰度发布是Istio最常用的场景。一步步来。场景v1升级到v2假设reviews服务要从v1升级到v2我们希望先放1%的流量到v2观察一段时间没问题逐步提高比例最终全量切到v2步骤一1%灰度apiVersion:networking.istio.io/v1beta1kind:VirtualServicemetadata:name:reviewsspec:hosts:-reviewshttp:-route:-destination:host:reviewssubset:v1weight:99-destination:host:reviewssubset:v2weight:1步骤二观察指标用Kiali查看流量分布kubectl apply -f https://raw.githubusercontent.com/istio/istio/release-1.20/samples/addons/kiali.yaml kubectl port-forward svc/kiali -n istio-system20001:20001打开http://localhost:20001能看到服务拓扑和流量比例。同时观察v2的错误率和延迟# Prometheus查询rate(istio_requests_total{destination_servicereviews.default.svc.cluster.local,destination_versionv2,response_code!~5.*}[5m])/ rate(istio_requests_total{destination_servicereviews.default.svc.cluster.local,destination_versionv2}[5m])步骤三逐步放量# 10% - 50% - 100%spec:http:-route:-destination:host:reviewssubset:v1weight:50-destination:host:reviewssubset:v2weight:50步骤四全量切换spec:http:-route:-destination:host:reviewssubset:v2weight:100自动化灰度Flagger手动调权重太麻烦可以用Flagger自动化apiVersion:flagger.app/v1beta1kind:Canarymetadata:name:reviewsspec:targetRef:apiVersion:apps/v1kind:Deploymentname:reviewsprogressDeadlineSeconds:60service:port:9080analysis:interval:1mthreshold:5maxWeight:50stepWeight:10metrics:-name:request-success-ratethresholdRange:min:99interval:1m-name:request-durationthresholdRange:max:500interval:1m这个配置每分钟检查一次成功率99%、延迟500ms才继续放量每次增加10%最高到50%如果连续5次检查失败自动回滚实战熔断降级配置熔断apiVersion:networking.istio.io/v1beta1kind:DestinationRulemetadata:name:reviewsspec:host:reviewstrafficPolicy:connectionPool:tcp:maxConnections:100http:http1MaxPendingRequests:100http2MaxRequests:1000maxRequestsPerConnection:10outlierDetection:consecutive5xxErrors:5interval:10sbaseEjectionTime:30smaxEjectionPercent:50解释consecutive5xxErrors: 5连续5个5xx错误就触发熔断interval: 10s每10秒检查一次baseEjectionTime: 30s熔断后30秒开始恢复maxEjectionPercent: 50最多熔断50%的实例测试熔断部署一个会随机返回500的服务# 造一些错误foriin{1..100};docurl-s -o /dev/null -w%{http_code}\nhttp://reviews:9080/reviews/1done观察Kiali会看到部分Pod被标记为ejected。实战故障注入测试服务的容错能力可以用Istio注入故障。注入延迟apiVersion:networking.istio.io/v1beta1kind:VirtualServicemetadata:name:ratingsspec:hosts:-ratingshttp:-fault:delay:percentage:value:10fixedDelay:5sroute:-destination:host:ratings10%的请求会延迟5秒。用来测试调用方的超时处理。注入错误spec:http:-fault:abort:percentage:value:10httpStatus:503route:-destination:host:ratings10%的请求直接返回503。用来测试熔断和重试逻辑。生产环境配置资源限制Sidecar会额外消耗资源生产环境要设置好apiVersion:install.istio.io/v1alpha1kind:IstioOperatorspec:values:global:proxy:resources:requests:cpu:100mmemory:128Milimits:cpu:500mmemory:256Mi访问日志apiVersion:telemetry.istio.io/v1alpha1kind:Telemetrymetadata:name:mesh-defaultnamespace:istio-systemspec:accessLogging:-providers:-name:envoymTLS服务间通信加密apiVersion:security.istio.io/v1beta1kind:PeerAuthenticationmetadata:name:defaultnamespace:istio-systemspec:mtls:mode:STRICT多集群管理大型系统可能有多个K8s集群Istio支持多集群网格。这种场景下需要确保集群之间的网络互通。如果集群分布在不同的网络环境比如多云、混合云网络打通是个麻烦事。我之前的做法是用星空组网把各个集群的节点串起来形成一个虚拟网络然后再部署Istio多集群。踩过的坑1. Sidecar启动顺序症状应用启动时连不上其他服务。原因应用容器比Sidecar先启动这时候Sidecar还没ready。解决spec:template:metadata:annotations:proxy.istio.io/config:|holdApplicationUntilProxyStarts: true2. 大文件上传超时症状上传大文件失败。原因Envoy默认超时太短。解决apiVersion:networking.istio.io/v1beta1kind:VirtualServicespec:http:-timeout:300sroute:-destination:host:upload-service3. gRPC流式调用问题症状gRPC streaming断开。原因Envoy的idle timeout。解决apiVersion:networking.istio.io/v1beta1kind:DestinationRulespec:trafficPolicy:connectionPool:http:idleTimeout:3600s4. 内存占用高症状Sidecar吃了太多内存。原因配置推送太频繁或者服务数太多。解决限制Sidecar的配置范围Sidecar CRD升级Istio版本新版优化了配置分发apiVersion:networking.istio.io/v1beta1kind:Sidecarmetadata:name:defaultspec:egress:-hosts:-./*-istio-system/*只加载本命名空间和istio-system的配置。总结Istio确实强大但复杂度也高。建议循序渐进先上基本的流量管理观测能力搞熟了再玩高级功能监控先行部署前把Prometheus、Grafana、Kiali、Jaeger都装好灰度上线新服务先在非核心业务试别一上来就全量版本跟进Istio更新很快及时升级能避免很多已知问题值不值得用如果你的微服务超过20个服务治理需求强烈那绝对值得。如果就三五个服务可能用起来比较重考虑轻量级方案比如Linkerd。