传统微服务架构如何落地
传统的微服务架构在项目中落地需要借助微服务框架和 SDK 的能力，那么微服务框架需要具备哪些功能，需要依赖什么环境，落地实践中又会遇到什么问题呢？
微服务框架功能及依赖的外部基础设施
一般来说，现代微服务框架需要具备以下功能。
服务注册发现：微服务的核心组件，负责服务的注册，以及 upstream 服务的 Endpoint 的发现。
路由：负责流量转发的配置。
负载均衡：具备多种负载均衡策略，针对 upstream Endpoint 进行流量分发。
服务治理：通常指的是限流、熔断、降级等可以提高微服务架构稳定性的措施。
可观测性：Metrics、日志、链路追踪等组件。
脚手架：微服务框架为了让业务快速上手，通常需要一个脚手架，让业务方快速生成项目代码。
RPC：这里指的是广义的 RPC，可以是 gRPC 或者 Dubbo 等 RPC 协议，也可以是 HTTP 协议。
以上是一个微服务框架的基本功能，只有具备了以上功能，框架才具备在公司内推广的可能性。
当然，整个微服务的生态在不断演进，结合公司的需求，适当增加一些新的功能也是有必要的，比如染色、通用 header 传递、金丝雀发布等。
下面微服务框架落地依赖于外部哪些基础设施。
边缘网关层：统一的入口网关层，作为微服务的入口层，负责南北流量的治理。
监控告警：收集业务的 Metrics、Trace、Log 等信息，并配置监控告警。
配置中心：负责微服务的系统配置的管理，比如 MySQL、Redis，以及上下游服务的调用配置等。
CI/CD：包含 CI 持续集成（Continuous Integration）和 CD 持续部署（Continuous Deployment）。
持续集成主要是指代码部署前的自动化测试和自动化编译打包的过程，持续部署是指编译打包后的代码部署发布的过程。
代码发布和部署分开，有利于版本控制和回滚，方便线上随时恢复到任意版本。
PAAS 平台：这里主要是指运维管理平台，主要包含机器的资源管理的 CMDB、微服务流程管理、服务治理平台等。
具体来说，在这个平台中，申请机器资源、各类中间件资源、数据库资源、缓存层资源，以及各种机器的权限等；
另外包括整个微服务的生命周期管理、服务治理的限流熔断等配置，都可以在这个一站式的服务平台解决。
PAAS 平台在微服务架构的落地中至关重要，对于提高产研效率起着关键作用。
微服务框架落地中的问题
微服务框架在落地的过程中，会遇到什么问题呢？
推广困难：在框架的落地中，亟须解决的是框架覆盖度的问题，但各个业务方往往都有自己的框架选型。特别是老项目，推动改进基本上就等于老项目重构，将耗费大量人力。
迭代升级困难：当需要迭代新功能或者修复 Bug 时，需要推动所有的框架接入方进行升级，升级往往需要业务方感知，拉取最新的框架 Tag，如果碰到不兼容更新的情况，简直是一场灾难。
排查问题：框架代码和业务代码混淆在一起，日志监控等排查信息也混合在业务代码中，发生问题时就需要框架方和业务方联合排查，而框架提供方需要在日志中找出和框架有关信息，无疑增大了排查问题的难度。
多语言：一般情况下，因为人力问题，团队只能维护公司主力语言的框架，而对于小众语言来说，基本上是无法提供框架支持的。
Service Mesh 架构如何落地
根据公司的运维环境不同，Service Mesh 落地路径，大致分为以下几种。
虚拟机环境：也就是传统的 VM 环境，这种环境需要控制面和公司的运维平台或者 CMDB 打通，需要做的事情较多，因为和 CMDB 耦合比较严重，所以维护成本较高。
Kubernetes 环境：纯 Kubernetes 环境相对比较容易，因为不再需要维护机器资源，只在 Kubernetes 的 Pod 中注入相应的环境变量，比如服务名、节点名称、环境等信息即可。
Kubernetes +虚拟机混合环境：如果公司面临虚拟机环境向 Kubernetes 环境的迁移，这种混合环境是不可避免的，但是此时涉及的问题就比较多，上面提到的两种环境都要支持，
而且服务的切流（指的是流量从虚拟机切换到 Kubernetes 上）也需要在控制面支持。
Service Mesh 架构落地中的优势
迭代升级：相对于传统的微服务框架，迭代升级无须业务方感知，可以独立演进。
多语言：无须关注公司主力语言，对于非主力语言，也作为“一等公民”同等对待。
灵活部署：为了快速落地，Service Mesh 架构并不一定非得全部接管入流量和出流量。在早期，只接管入流量（也就是服务端流量），会更容易一些，因为接管出流量往往需要改动客户端代码，
而接管入流量只需修改 LB 代理的端口，或者由 Sidecar 代理注册即可。
在后期的一些场景中，也有部分服务端因为性能问题，不希望让 Sidecar 接管入流量，这个时候可以灵活地在调用端部署 Sidecar ，接管调用端服务的出流量，这样既兼顾了性能，也解决了微服务框架中最难解决的客户端 SDK 升级的问题。
Service Mesh 架构落地中的困难
在实际的 Service Mesh 落地过程中，虽然解决了微服务框架的诸多问题，但也并非一帆风顺，新的架构也带来了新的问题。
排查问题
一次服务调用，在链路上会增加两次调用，这确实给排查问题带来了不便。本来只需排查服务自身的问题，现在却要经常考虑是不是 Sidecar 出现了问题。
解决排查困难的问题，只能从可观测性入手，比如增加丰富的 Metrics 指标、打印关键日志、记录 Trace 链路。
性能
上面也提到了，每次调用会多出两次请求，这就导致增加延时和服务器资源消耗的问题无法避免。在落地过程中，性能这个点是被业务方挑战最多的，毕竟这是实打实可以看到的损耗。这就需要我们尽可能提升 Sidecar 的代理性能、延时和 CPU 消耗。比如延时，HTTP 的单次代理延时消耗大概增加 0.3ms，而私有的 RPC 协议可以做到小于 0.1ms。这样的延时，大部分的业务场景都可以接受。
另外也可以从架构的优势上多和业务方探讨，毕竟性能不是架构是否合理的唯一指标。微服务架构中的服务拆分，也造成了不小的性能损耗，保证业务的稳定性、可扩展性、迭代速度也是非常重要的衡量指标。
信任问题
实际上，常规中遇到的一些技术问题，相对来说都比较容易解决。但在实际的推广落地中，往往会碰到业务方和技术负责人不信任的问题，甚至在基础架构内部也可能出现不同声音。新的技术架构代替老的技术架构，如何解决信任问题往往是最重要的。信任问题的原因，说起来也很简单，就是大家对新的技术了解程度不够，所以会产生很多误解。
比如对于 Service Mesh 这个架构来说，除了上面提到的排查不便问题和性能问题之外，还容易碰到以下几方面的疑问。
Sidecar 导致了服务不稳定
在某些情况下，服务使用 Sidecar 可能会有一些异常的抖动。这些问题可能是上 Sidecar 导致的，也可能是因为服务本身的功能迭代，但是这种不稳定需要根据具体问题排查。比如在落地中，就遇到过因为 Http Client 参数配置不合理导致上 Sidecar 之后出现服务抖动；也遇到过服务自身的业务迭代或者机器资源不足导致的问题，这种情况一定要连同业务方一起排查问题，找出根因。
服务调试不方便
因为架构的变化，需要在每个服务的机器上部署 Sidecar 进程，这就导致了开发环境不方便的问题，这个问题可以通过调用远程 Sidecar 的方式解决。至于测试环境和预发布环境，只要和运维平台做好整合，自动化部署即可。
Sidecar 增加了延时
在实际排查问题过程中，经常有业务方同学根据 Trace 日志定位问题，找到我们。他们通过 Trace 日志中的表象，反映 Sidecar 大大增加了延时。这种情况往往出现在服务异常的时候，从 Trace 链路看，Sidecar 的环节确实相对服务延时较高。但大多数情况下，都是机器资源问题导致，因为服务的 Trace 链路实际上是无法跟踪网络和系统层面的消耗的，此时这部分消耗会被记录在 Sidecar 的 Trace 链路中。遇到这种问题，只能耐心跟业务方同学解释。
标签：服务,落地,框架,架构,问题,如何,Servicemesh,Sidecar From： https://www.cnblogs.com/muzinan110/p/17060264.html