随着流量的增加和团队的成长，为了适应变化，扇贝的服务器在2017年进行了大规模的改造，包括微服、集装箱整理等。从而大大提高开发效率，降低维护成本。微服务的服务间通信和服务治理是微服务架构实现中的两个核心问题。希望这个分享可以启发中小型互联网公司实践微服务。
自从我们的微服务第一次大规模尝试和使用以来，已经快两年了。回想起来，我踩过无数坑，有技术的，也有管理的。是不是很有经验。今天，我主要想和大家分享微服务的选择、DevOps实践、服务治理和服务网格。
你想要微服务吗
个人认为应该慎重选择微服务，考虑微服务可能带来的挑战。我们必须根据自己的实际情况仔细决定是否需要微服务。
网上有很多关于微服好处的介绍。这里我想强调的是，从“人”的角度来看，微服务带来的优势和挑战。
在微服务架构下，每项服务的复杂性大大降低，从而维护成本也大大降低。对于团队来说，新人也可以更快地进入项目并贡献代码。项目移交也变得更加容易。
单一服务架构下，随着时间的推移，项目的复杂度必然会越来越高，相关人员也会越来越多，从而导致代码合并频率逐渐降低，权限分配越来越困难，测试越来越繁重，部署越来越复杂，频率越来越低。
然而，微服务也带来了许多问题。比如设计不合理，整体复杂度会增加。在编写代码时，需要考虑调用失败和分布式事务的情况(当然往往是设计不合理造成的)，这对人提出了更高的要求。
总之，微服务带来了许多优势和挑战。我们需要仔细审视自己，这些优势现在对我们来说是否是优势，这些挑战现在是否能抓住我们。
关键问题1:如何划分微服务
以下是一些提示:
区分边界服务和内部服务。所谓边界服务就是会接受公网流量的服务，比如处理 HTTP 请求的服务，反之就是内部服务。边界服务和内部服务在安全方面的考虑是不一样的（例如边界服务需要做针对User的鉴权等等）。区分基础和业务服务。业务服务追求变化，feature，基础服务追求稳定，性能。微服务的调用，一定要考虑调用会失败。微服务的提供方，一定要考虑调用可能会有bug（比如死循环）。没有把握的做到合理拆分的时候可以选择先不拆，等到发现瓶颈了自然就知道怎么拆了。关键问题2:微服务和开发平台
微服务不仅是一种技术活动，也是一种管理活动。必须有一个与微服务集成的团队组织和工作流。
首先是成立架构组。
架构组负责微服务的基础设施建设，如CI/CD系统、Kubernetes集群、Service Mesh集群、监控报警系统、日志采集系统、基础工具和库建设维护。
总之，团队中架构组的意义可以理解为为内部构建PaaS。
业务团队(无论是写基础业务还是其他业务)可以从架构团队获得稳定可靠的PaaS和一套支持工具。
其次，每个微服务都应该有一个固定的团队来负责它(实际上，微服务可以被分组，每组微服务对应于一个特定的人群)。
每个团队负责自己的微服务的开发、启动、维护、性能调优和调试。
总之，每个团队都应该对自己的微服务完全负责。
在我们的实践中，每个微服务团队由2-3人组成，有一个主，负责DevOps流程的构建，权限的分配等等。
比如我们的DevOps是基于GitLab CI和Kubernetes的，所以master负责编写和维护gitlab-ci.yml以及Kubernetes与其自身服务相关的所有部署、作业、服务等等。
另外，你要负责项目的线上运营，比如设计自己具体的监控指标和报警策略。这些又反过来指导您自己的维护和调整。
不同的微服务团队相互独立，通过gRPC和芹菜实现数据交换。
服务间通信
从通信类型来看，大约有三种:同步调用、异步调用和广播。
在微服务的设计之初，需要清楚的知道调用关系和调用方式，哪些需要同步，哪些可以异步，哪些需要广播。最好是团队内部有统一的认识。
那么就需要确定调用协议。例如，常见的选择有:
同步调用：HTTP REST、gRPC、thrift，etc。异步调用：Sidekiq、Celery，etc。对应的backend有 Redis，各类 AMQP 实现，Kafka 等等。广播：各类 AMQP 实现，Kafka，etc。如何选择，需要多角度思考。网上有很多“X vs Y”的文章或者问答。其实是从几个角度:性能、成熟度、易用性、生态、技术团队。我们的建议是:优先考虑那些活跃在社区，并与自己团队技术栈融合的人。社区中活跃的技术往往代表潮流和生态，团队技术栈的兼容性是成功的保证。
比如扇贝选择gRPC作为同步调用的接口协议。主要考虑两点:1。社区活跃，发展非常迅速；2.基于HTTP/2，与我们的技术栈兼容。
除了选择协议，更重要的是管理接口文档。最好的接口文档和代码紧密相关，就像gRPC的proto和生成的代码一样。不然人就容易偷懒，很有可能代码变了，文档没变。
总之，关于服务间沟通，我们需要做好:
确定接口规范，什么用同步调用，什么用异步，什么用广播；同步调用用什么协议，异步用什么确定接口协议，以及思考接口文档的管理，接口文档与代码之间如何建立强联系服务治理
服务治理是一个很大的话题。如果真的要谈，谈不完很久。
在这里，我们想简单地看一下服务治理要解决的问题，以及一些当前的解决方案和发展趋势。最后，以扇贝为例，简要介绍了如何在一个真实的几百万天的生产环境中做服务治理。
什么是服务治理？
微服务带来很多好处，比如通过将复杂的系统划分成若干个微服务来分解和降低复杂性，这样这些微服务就可以很容易被小的开发团队理解和维护。但是也带来了很多挑战，比如微服务连接、服务注册、服务发现、负载均衡、监控、AB测试、加那利发布、限流、访问控制等等。
这些挑战就是服务治理的内容。
除了新的star Service Mesh，还有Spring Cloud等解决方案。
这些方案的问题如下:1 .入侵代码意味着如果你想改变框架，你必须改变很多东西。2.语言专用性(Java)，如果用Go/Python，或者我们的微服务不全是Java，我们就做不到。
然后出现了服务网格方案。其实DockOne上关于Service Mesh的介绍太多了。不想在这里浪费大家的时间，就不赘述了。我将直接介绍我们如何使用服务网格。
扇贝服务网
扇贝的服务网格是基于invite和Kubernetes实现的。
首先介绍一些前提:扇贝微服务都是容器化的，编排系统基于Kubernetes，同步调用基于gRPC，异步调用基于芹菜[兔】。Python 3、Node.js、Go是主要的开发语言，Service Mesh是基于invite的。
总体方案是:特使以DaemonSet的形式部署到kubernetes的每个节点，采用Host网络模式。微服务的所有PODs向其节点的特使发送gRPC请求，特使执行负载平衡。如下图所示:
以下是一些详细的解释:
Envoy 中的 Route 类似于 Nginx 的 Location，Cluster 类似于 Nginx 的 upstream，Endpoint 对应于 Nginx 的 upstream 中的条目。之所以选择 Envoy 而没有用 Linkerd，是因为当时 Envoy 是对 HTTP/2 支持最好的。且资源消耗更少。之所以选择 Host 网络模式是为了最大化提高性能。对于 Enovy 而言，服务发现就是告诉 Envoy，每个 Cluster 背后提供服务的实例的IP（对应于 Kubernetes 也就是 Pod 的IP）是什么。最开始服务发现是利用 Kubernetes 的 DNS，因此，在创建Service的时候，要使用 ClusterIP: None。后来的服务发现是基于 Kubernetes 的 Endpoint API 实现了 Enovy 的 EDS（这个项目我们日后会开源到 GitHub 上）。对于 Envoy 而言，实现熔断，只要实现 rate limit service 就行了。我们基于Lyft/ratelimit 实现的 rate limit service。微服务之间的调用情况都可以通过 Envoy 的 statistic API反映出来，所以我们针对 statistic API做服务调用的监控报警。同理，调用日志也可以利用 Envoy 的 Access Log 来实现。之所以不用istio，是因为生产环境真不能用。性能问题，稳定问题太过突出。监控警报和日志收集
我们的监控和报警方案是基于普罗米修斯的，分为三个层次:集群层次，包括Node的状态，集群核心组件的状态等等。
集群级别是架构组关心的， 基础服务级别是所有人都要关心的，业务自定义级别就是微服务团队关心的基础服务级别：包括 Service Mesh 的各种指标（例如请求量，请求时间等等），Redis、MySQL、RabbitMQ 等业务自定义级别：包括各个微服务团队自己设计的监控指标直接向同一个钉钉组报警，互相监督。
上面的例子是我们“Word Master”团队自定义的监控指标，包括他们唯一的“Match API Received”(即调用Match API的次数)等等。
至于日志，基本上用的是:container->:stdout->；file beat->；卡夫卡-& gt；Logstash ->ES(常规存档)。所有容器的日志都直接键入stdout/stderr。
顺便说一下，我们的日志系统方便程序员调试，同时也负责收集一些数据。所有的打点数据也都记录在卡夫卡-->:Logstash那一步整理出来的。
比如上图是我们整理的一些gRPC的通话日志。
问答。A
问:普罗米修斯只收集库本内特斯集群的索引数据，那么用什么来收集非库本内特斯索引数据呢？
答:都是普罗米修斯。应用程序可以安装普罗米修斯的客户端，并公开自己的指标。那么Redis等东西也有出口商。
问:如果所有日志都落入stdout，是否会出现格式不一致，导致收集和归档困难？例如，如果业务日志和中间件日志都命中了stdout，那么它们在Filebeat或Logstash中是如何处理的？另外，定期删除容器日志的策略是什么？
答:这个问题问得好。需要排序的日志将被标记在消息的开头。例如，[DATABET]表示打点数据。ES有很多工具可以定期存档，比如需要保留多少天和几个月，这取决于不同的数据策略。
问:Q:特使损失多少性能，自身消耗多少？
答:invite有性能损失，因为API的平均响应时间差不多是100-150 ms，相对于它带来的好处，我们认为这些损失是值得的，所以没有具体衡量。
问:gRPC是否注册了该服务，以及如何处理GRPC新增和缩减字段的兼容性？
答:服务注册/发现是基于Kubernetes和我们编写的Kubernetes Endpoint到特使eds的转换服务。
问:问:Istio和特使是什么关系？
答:istio包括一个控制平面+数据平面，invite可以作为Istio数据平面的一个实现。
库伯内特公司简介和高级实践培训
本次培训内容包括:Docker基础、容器技术、Docker镜像、数据共享和持久化、Docker三驾马车、Docker实践、Kubernetes基础、Pod基础和高级、通用对象操作、服务发现、Helm、Kubernetes核心组件原理分析、Kubernetes服务质量保证、调度详解和应用场景、网络、基于Kubernetes的CI/CD、基于
1.《扇贝网 扇贝网微服务编排和治理实践》援引自互联网，旨在传递更多网络信息知识，仅代表作者本人观点，与本网站无关，侵删请联系页脚下方联系方式。
2.《扇贝网 扇贝网微服务编排和治理实践》仅供读者参考，本网站未对该内容进行证实，对其原创性、真实性、完整性、及时性不作任何保证。
3.文章转载时请保留本站内容来源地址，https://www.lu-xu.com/guonei/859920.html
