作者介绍：
罗广明 字节跳动服务结构团队架构师
先后在爱立信、百度从事云原生、微服务以及开源相关作业，后参加字节跳动，负责 CloudWeGo 等微服务项目开源相关作业。长时刻重视云原生 & 微服务范畴前沿技能、架构演进以及规范化作业。
2022 年，关于微服务产生了几件有趣的事情。其一，正式掌管 Twitter 不久的 Elon Musk 对 Twitter 的开发团队 “批判” 了一番。他表明自己为 Twitter 在许多国家的极慢运转速度感到抱愧。之所以如此慢是因为 App 需求执行 1000 多个 “糟糕” 的批处理 RPC，而这仅仅为了烘托主页的时刻线。Musk 表明 “今天的部分作业将是关闭臃肿的”微服务” 。实际上，只有不到 20% 的微服务是 Twitter 需求的。” 其二，GitHub 前 CTO Jason Warner 在社交媒体上表明：“我坚信曩昔十年中，最大的架构过错之一便是全面运用微服务。” “任何构建过大型分布式体系的人都知道他们并不真的那样作业，但还必须适应它。”那么，微服务架构是否是一个过错，或许微服务是否现已过期了呢？
一、事务是否需求微服务
微服务的来源，最早可以追溯到 2005 年 Peter Rodgers 博士提出的 Micro-Web-Service，行将运用程序规划成细粒度的 Web 服务。2014 年，Martin Fowler 与 James Lewis 首次正式提出了微服务的概念，界说了微服务架构是以开发一组小型服务的方式来开发一个独立的运用体系，每个服务都以一个独立进程的方式运转，每个服务与其他服务运用轻量级通讯机制（ RPC 、HTTP）通讯。这些微服务是环绕事务功用构建的，可以选用不同的编程言语。
微服务的诞生绝非偶然，CICD & Infrastructure As Code 的呈现与展开，使得根底设施管理逐步简化、功用迭代也更快速和高效，推动与促进了微服务的进一步展开和落地。
但是，微服务架构并非银弹，微服务架构给事务带来收益的一起，也会带来相应的副作用。在适宜的阶段选用微服务架构、合理决议微服务架构的拆分粒度以及恰当的微服务技能选型是决议微服务胜败的中心。 摒弃上述三点不谈，大举打击微服务存在的必要性，摇旗呐喊重回单体年代的言论都是站不住脚的。仔细剖析 GitHub 前 CTO Jason Warner 的观念，你会发现，其倡议的是从单体到微服务的有序拆分和推动，而且微服务的拆分数量需求适宜安排规划，Warner 鼓舞企业依据自己的情况来挑选，而不是盲从。这和上述倡议的观念本质上是一致的。
适宜的阶段选用微服务架构
据观察，简直一切成功的微服务架构都是从一个巨大的单体架构开始的。面对一个新的产品以及一个新的范畴，很难在一开始就把事务理解明晰，往往是经过一段时刻后，事务逐步弄清楚之后，才会逐步转型成微服务架构。此外，在物理资源和人力资源受限的情况下，选用微服务架构的风险较大，许多优势无法体现，特别在技能选型不其时，微服务功用上的下风反而会愈加突出。
在微服务区分之前，也应该确保公司内部的根底设施及公共根底服务现已准备完备。 可以经过监控组件和产品快速定位服务毛病，可以经过东西自动化布置与管理服务，可以经过一站式开发结构下降服务开发的本钱，可以经过灰度发布和泳道验证和提高服务的可用性，可以经过资源调度渠道快速申请与释放资源，可以经过弹性弹性服务快速扩展运用。
合理决议微服务架构的拆分粒度
微服务架构的拆分粒度应当合理，微服务架构中的微字，并不代表粒度越小越好，也不代表越多越好，应当寻求一个合理的中心值。粒度过微，微服务的缺陷将被放大，此刻的微服务相关于原先的单体的确弊大于利；粒度不够，单体的缺陷并未消除，微服务的长处并未凸显，也是不合理的。微服务架构的粒度拆分是一件适当杂乱的事情，关于事务和团队安排架构理解不深的新人或许外部人员，根本无法判别合理的微服务拆分粒度。
跟着事务的展开，安排架构的改变，团队开发人员水平的提高，粒度随时或许产生改变，这是一个不断演进的过程，没有肯定的对错。微服务架构的规划与微服务的拆分应当契合康威定律，即微服务架构需求与产生这些规划的安排架构保持一致，乃至是动态一致。
当然，仅仅熟悉事务和团队安排架构是不够的，也需求合理的微服务拆分战略。例如，比较独立的新事务优先选用微服务架构、优先笼统通用服务、优先笼统边界比较明晰的服务、优先笼统具有独立属性的服务。终究，主张优先笼统中心服务，因为微服务的运维本钱较高，不是一切的当地都需求拆分，此外跟着时刻的推移，事务或许产生改变，而中心服务比较安稳然后不需求做较大调整。
恰当的微服务技能选型
决议运用微服务后，微服务相关技能选型至关重要。微服务结构可以封装、笼统分布式场景下的通用才干，例如负载均衡、服务注册发现、容错以及根本的长途通讯的才干，可以让开发人员快速开宣布高质量的服务。因而，在选用微服务之前，应当进行开发言语的挑选以及对应的微服务结构的选型与试用。
那么该怎么挑选微服务结构呢？主张从扩展性、易用性、功用丰厚度以及高功用四个视点进行衡量。
- 首先是扩展性，一个开源结构假如与内部才干强耦合、支撑场景单一且无法进行扩展，那这个结构则很难在企业内部定制化的场景下进行落地。
- 其次是易用性，事务开发者不希望重视许多结构底层细节，运用起来需求满足简略；而面向结构的二次开发者，他们需求对结构做一些定制支撑，假如结构供给的扩展才干过于宽泛让扩展本钱很高，或答应扩展的才干不够多，那这个结构也是存在局限性的。
- 再次是功用丰厚度，虽然依据扩展功用够对结构进行定制，但不是一切开发者都有满足的精力做定制开发，假如结构自身对各种扩展才干供给了不同挑选的支撑，关于开发者来说只需求依据自己的根底设施进行组合就能在自己的环境中运转。
- 前面三点是微服务转型初期挑选微服务结构需求重点重视的目标，但跟着服务规划和资源耗费变大，功用就成了不容忽视的问题，从长时刻来看，挑选结构的时分必定要重视功用，不然后续只能面对结构替换的巨大本钱问题或许被迫对这个结构做定制优化与保护。
总的来说，微服务并非银弹，可是单体相同有许多缺陷，微服务是在单体架构之上自然衍生展开出来的一个面向现代化与 云原生 的架构，是大势所趋。仅仅事务需求在适宜的阶段选用微服务架构、合理决议微服务架构的拆分粒度以及进行恰当的微服务技能选型。 假如步子迈得太快，服务拆分不合理，技能选型犯了一些过错，架构需求回退到单体，这也是单个事例，但也是咱们需求警惕和引以为戒的。
二、微服务进入深水区后该何去何从
微服务火了近十年，环绕微服务诞生了许多技能创新和开源项目，也有适当多的企业在内部完结了微服务的落地与推广。以字节跳动为例，近年来其微服务数量和规划迎来快速展开，2018 年，在线微服务数大约是 7000-8000，到 2021 年底，微服务数量 现已 突破了 10 万。 企业内部的微服务数量能到达如此规划是适当少见的，但这也意味着微服务在字节得到了深度的展开，那么下一步路在何方呢？
结合字节跳动服务结构团队实践以及业界趋势， 咱们认为 后续的微服务展开方向首要 会 环绕安全、安稳性、本钱优化以及微服务管理规范化打开。
微服务安全
在微服务架构中，微服务的数量跟着事务的分化和添加呈指数添加。因为微服务分布在不同的服务器上，因而与同一渠道的单一完结相比，微服务一般会暴露出更大、更多样化的攻击面，这使得赶快发现和修复漏洞以避免问题变得愈加困难。因而，每个微服务都需求对用户的行为进行认证和答应，明确当前拜访用户的身份与权限级别。与此一起，整个体系或许还需求对外供给必定的服务，比方第三方登录授权等。在这种情况下，假如要求每个微服务都完结各自的用户信息管理体系，既添加了开发的作业量，犯错的概率也会添加，因而，一致的认证和授权以及支撑按需敞开 mTLS 就显得特别重要。
服务判定 是一种依据身份标识校验请求身份合法性的微服务拜访操控才干。 服务经过为详细办法或通配办法装备大局开关为敞开状况，到达严厉的身份判定的作用。为了配合合规要求，字节跳动展开了跨事务线数据拜访专项管理，管理的一个先决条件便是全面落地零信任（ZTI）的服务身份，然后辨认数据请求方的可信身份进一步完结细粒度拜访操控来满意用户隐私合规要求，保障微服务接口安全和避免相似删库这样的误操作。
严厉授权是一种依据允许拜访列表+不允许拜访列表的微服务拜访操控才干。 服务经过为详细办法或通配办法装备对上游服务的详细集群或通配集群授权，结合大局开关为敞开状况，到达严厉的拜访操控作用。
部分 RPC 结构自身也具有严厉授权才干，但不同结构关于该才干的完结是不对齐的，而且越来越难以满意事务的装备需求。字节跳动依据服务网格 ByteMesh 来完结一致的严厉授权才干，这也得益于服务网格技能现已在字节跳动内部完结了全面的落地。
微服务安稳性
线上服务安稳性对互联网运用至关重要，安稳性差的服务将带给用户不好的运用体会，乃至给企业造成直接的经济损失。衡量服务常态安稳性一个重要目标是 SLO（Service-Level Objectives），代表服务可用水平目标。例如将服务接口的成功率 SLO 定为 99.99%，一周内低于 SLO 基线的不可用时长少于 X 小时，超越 X 小时就表明该服务安稳性不合格。一般，微服务的管理才干，如超时、重试、容错、限流等才干可以满意大多数场景，提高微服务的安稳性。字节跳动内部微服务化水平高、规划大，为了做好精细化的服务管理，诞生了单实例管理与动态过载保护等一系列服务管理计划，进一步提高微服务的安稳性。
微服务化、大规划分布式布置带来了必定的运维担负，乃至有些时分，事务很难分辩问题的范畴是根底设施还是事务自身。其间，最为常见也往往不需求事务感知的问题是：很少部分（一个或几个）实例的服务才干异常导致服务 SLA 颤动。咱们将这类问题统称为单实例问题。单实例问题的成因杂乱，混杂了物理层面、事务层面等多种要素，而且简直无法彻底根除。
为了下降单实例问题的事务感知、提高事务中心服务的 SLA，字节跳动服务结构团队依据服务网格 ByteMesh 的动态负载均衡才干构建了单实例问题颤动管理的处理计划。该计划经过收集 ByteMesh 数据面上报的 RPC 相关目标（延时、过错率等）、服务端实例的负载目标（排队时刻、 CPU/MEM/IO 运用率等），动态更新服务端实例的权重，来到达服务负载更均匀的作用。该中心化操控计划在抖音电商等事务经过大规划验证，有用提高了毛病辨认的功率。以某一个详细服务为例，当产生单实例毛病，默许装备在 1min 以内会执行服务发现降权或去除，因而服务 SLO 不可用时长操控在 1min 以内，而且供给了单实例管理去除大盘，可以便利排查单实例问题。
微服务本钱优化
在云原生年代，跟着微服务的不断拆分和大规划添加，呈现微服务过微是必然 会 面对的问题， 由此带来的 额定推迟和资源耗费等缺陷越发凸显。 业界也呈现了许多反微服务的声音，呼吁回归单体。但是单体愈加不是银弹，回归单体无异于饮鸩止渴，更不契合事务展开趋势。为此，针对微服务的本钱优化，字节跳动探究出了许多途径，包括但不限于兼并布置、JSON 序列化优化、开发结构开支优化等。此外，在公司推动本钱优化的背景下，服务结构团队与事务、其他根底团队促进更多的协作，力求挖掘出更多功用优化点。
兼并布置
字节在微服务架构之上对功用优化计划做了深化探究，探究了多种兼并布置计划。虽然业界其他公司对兼并布置也有过一些探究，但相关计划在编译、布置、监控、服务管理、服务阻隔多个方面对现有体系的冲击较大，无法很好地支撑现有体系，一起布置存在相互影响导致协作功率下降的问题。针对这一问题，根底架构团队提出了一种新的兼并布置计划，结合容器亲和性调度、流量调度核算、更高效的本地通讯，让原本需求跨机的网络通讯变成同机进程间调用，既能与现有体系交融又能削减微服务链路带来的功用损耗。在 QCon 2021 上，根底架构服务结构团队对外共享了《字节跳动微服务兼并布置实践》，得到业界其他公司的广泛重视。兼并布置计划首要思路是结合容器亲和性调度、流量调度核算、更高效的本地通讯，让原本需求跨机的网络通讯变成同机进程间调用，既能与现有体系交融又能削减微服务链路带来的功用损耗。
以 IO 密集型测试服务为例，落地兼并布置计划后，CPU 下降了 30% – 40%，推迟愈加安稳，波动问题也没有了。现在兼并布置现已在字节多个事务方落地，在完结功用及战略的进一步优化后，经过大局决策操控，兼并布置有望在全公司范围内大规划落地。
JSON 序列化优化
JSON 以其简洁的语法和灵敏的自描述才干，被广泛运用于各互联网事务。可是因为 JSON 本质上是一种文本协议，且没有相似 Protobuf 的强制模型约束，编解码功率往往非常低下。再加上有些事务开发者对 JSON 库的不恰当选型与运用，终究导致服务功用急剧劣化。字节跳动也遇到了上述问题。依据此前核算的公司 CPU 占比 TOP 50 服务的功用剖析数据，JSON 编解码开支总体接近 10%，单个事务占比乃至超越 40%，提高 JSON 库的功用至关重要。因而字节跳动自研了一套 JSON 高功用编解码库 sonic-go 以及适用于 C/C++ 服务的 sonic-cpp，现在均已开源在 Bytedance GitHub 安排下。
在规划 sonic-go 的过程中，团队借鉴了其他范畴/言语的优化思维（不仅限于 JSON），将其交融到各个处理环节中。其间较为中心的技能有三块：JIT、lazy-load 与 SIMD 。除了上述提到的技能外，sonic 内部还有许多的细节优化，比方运用 RCU 替换 sync.Map 提高 codec cache 的加载速度，运用内存池削减 encode buffer 的内存分配等等。自 2021 年 7 月份发布以来， sonic-go 已被抖音、今天头条等诸多事务选用，累计为字节跳动节省了数十万 CPU 核。现在 sonic-go v2 正在规划研制中，预计将获得更大功用提高。
而 sonic-cpp 则在规划上整合了 rapidjson ，yyjson 和 simdjson 三者的长处，并在此根底上做进一步的优化。在完结的过程中，首要经过充分利用向量化（ SIMD ）指令、优化内存布局和按需解析等关键技能，使得序列化、反序列化和增修改查能到达极致的功用。sonic-cpp 在字节内部上线以来， 已为抖音、今天头条等中心事务累计节省了数十万 CPU 中心。
sonic-go 与 sonic-cpp 均兼容常见 json 库的一切接口，改造本钱极低，便利存量服务的快速搬迁。事务规划越大，搬迁到 sonic-go 与 sonic-cpp 的事务所获得收益则更多。
开发结构开支优化
关于事务来说，挑选高功用的编程言语很重要，可是往往受限于研制团队的技能栈和历史背景。且言语的搬迁往往本钱较大，也需求很大的动力来推动。关于一些创业公司，或许关于具有必定规划的公司的新增事务线来说，Golang 在云原生年代是最好的挑选之一，其学习本钱不高，关于云原生生态友爱，且具有较高的功用体现。
2014 年，Golang 被引入字节跳动，以快速处理长衔接推送事务所面对的高并发问题。随后，技能团队推出了 Kite 和 Ginex （依据 Gin 的扩展）结构，这两个原始结构的推出，极大推动了 Golang 在公司内部的运用。在 Kite 和 Ginex 发布之初，因为许多功用版别过低，包括 Thrift 其时只有 v0.9.2，它们其实存在许多问题，再加上 Golang 迎来数轮大版别迭代，Kite 和 Ginex 在功用与可保护性上存在较大问题 。综上种种原因，服务结构团队正式启动了 Kite 这个字节自有 RPC 结构的重构，新的结构命名为 Kitex。这是一个自下而上的全体晋级重构，环绕功用和可扩展性的诉求打开规划。相似的规划思路和底层模块也被运用在字节跳动自研 Golang HTTP 结构 Hertz 上，该项目相同具有高功用与高可扩展性。尔后，Kitex 与 Hertz 进入了大规划落地的阶段，而且仍旧在环绕功用和扩展性方面继续迭代与优化。2022 年，Kitex 启动了序列化与 Thrift 专项优化，进一步提高与优化内容复制以及 IO 操作相关的开支。
在挑选了 Golang 的条件之下，挑选适宜的 Golang 微服务结构相同是至关重要的。如前面所言，最适宜的微服务结构应当一起具有高可扩展性、高易用性、高功用以及内置功用满足丰厚。CloudWeGo 正是这样的开源的微服务结构与中心件集合，包含了上述字节开源的 Kitex 与 Hertz，是 Golang 范畴推荐的微服务结构，也是 CNCF Landscape 推荐的微服务结构。CloudWeGo 除了在字节内部事务大规划落地外，自 2021 年开源以来，现已在森马、华兴证券、贪玩游戏、禾多科技、沐瞳科技等数十家企业落地，依据 CloudWeGo 构建的微服务落地规划从数十个到上千个不等，上线后均获得了功用和安稳性上的收益。
微服务管理规范化
微服务离不开配套的管理才干，如服务可观测、全链路压测与灰度、注册发现、装备中心等，这些管理才干的完结依托于服务结构、SDK、Java Agent 以及服务网格。在这些技能的展开过程中，业界逐步形成百花齐放的局势，产生了不同的开发言语、结构和架构，这给企业带来了深重的保护担负以及技能选型上的困扰。而且，不同结构之间的互通也存在各类损耗和高杂乱度等问题，不同的微服务开发结构及东西链，关于服务管理体系的理解和完结存在差异性，不利于微服务技能的沉积及长时刻展开。终端用户必须在不同的根底设施和适当的东西之间做出困难的抉择，才或许处理微服务架构落地过程中的各种问题，加大了企业在微服务架构落地过程中的本钱。
为了处理这一难题，2022 年诞生了两套微服务管理规范化计划，面向多言语、多结构和异构根底设施，包括流量管理、服务容错、服务元信息管理、安全管理等关键管理范畴，供给一系列的管理才干与规范、生态适配与最佳实践。
2022 年 3 月，NextArch 基金会正式宣布成立微服务 SIG，来自腾讯、字节跳动、七牛云、快手、BIGO、好未来和蓝色光标等多家企业的技能专家成为第一批成员。该小组致力于推动微服务技能及其开源生态的继续展开，将面向企业在微服务生产实践中遇到的问题，针对不同行业和运用场景输出规范化处理计划，而且联合 PolarisMesh、TARS、go-zero、GoFrame、CloudWeGo 和 Spring Cloud Tencent 等开源社区供给开箱即用的完结，然后下降微服务用户的落地门槛。依据各自企业在分布式或许微服务生产实践中的经历和痛点，面向多言语、多结构和异构根底设施，针对不同行业和运用场景输出微服务落地的规范化计划，而且依托相关开源社区供给推荐完结，便利终端用户落地。
2022 年 4 月，微服务管理规范 OpenSergo 项目正式开源。OpenSergo 是敞开通用的，覆盖微服务及上下游相关组件的微服务管理项目，从微服务的视点动身，包括流量管理、服务容错、服务元信息管理、安全管理等关键管理范畴，供给一系列的管理才干与规范、生态适配与最佳实践，支撑 Java, Go, Rust 等多言语生态。OpenSergo 项目由阿里巴巴、bilibili、中国移动、SphereEx 等企业，以及 Kratos、CloudWeGo、ShardingSphere、Database Mesh、Spring Cloud Alibaba、Apache Dubbo 等社区联合发起，共同主导微服务管理规范建设与才干演进。OpenSergo 的最大特色便是以一致的一套装备/DSL/协议界说服务管理规矩，面向多言语异构化架构，覆盖微服务结构及上下游相关组件。
全体来看，微服务管理规范尚处于前期建设阶段，从微服务管理规范界说，到操控面的完结，以及 Java/Go/C++/Rust 等多言语 SDK 与管理功用的完结，再到各个微服务生态的整合与落地，都还有大量的演进作业，需求进一步迭代和完善。
三、总结与展望
微服务并非银弹，但也并非过期。微服务不是香饽饽，落地微服务有必定的应战；微服务也不是豺狼虎豹，无需避而远之。微服务的继续高速展开，使得它现已和核算、存储、网络、数据库、安全相同成为云核算的根底设施。只不过在每个不同的展开阶段，微服务面对的应战并不相同。云原生普及之前，微服务开发者专心的是微服务的架构、迭代、交给和运维。跟着云原生技能的老练，微服务也在被云原生化，这时分，开发者和架构师更关心的是怎么凭借云的优势，简化微服务的管理与运维，并更专心在事务的交给功率上。高功用的服务结构选型与搬迁以及微服务管理的规范化相同是微服务进入深水区需求继续探究的方向。
跟着云原生和微服务的展开，服务网格应运而生，咱们一般将以服务网格为中心的架构称为云原生微服务架构。云原生微服务架构具有以下四个特性：具有弹性核算资源；具有原生微服务根底才干；服务网格一致流量调度；处理多言语 RPC 管理和晋级问题。 此外，服务网格的落地可以更好地完结微服务的安全管控和安稳性管理。但是，服务网格相同不是银弹，并不能处理一切问题。云原生微服务架构下，Sidecar 添加了体系与运维的杂乱性，部分社区完结功用体现不佳还会带来显著的微服务通讯时延，组件多言语 SDK 的问题依然存在且非常严重，通用服务依靠如网关仍需显式接入等。
为了让通用才干继续下沉以及完结服务网格根底才干复用，促使云原生微服务架构逐步演进到多运转时微服务架构（Multiple-Runtime Microservices）。多运转时微服务架构完结多言语 SDK 的进一步下沉，且供给了安全、灵敏、可控的变更。 当然，多运转时架构也存在必定的局限性，事务仍需进行改造才干接入，且运转时资源与事务资源存在竞赛会引发一些较为杂乱的问题。为了处理这些问题，咱们希望完结愈加规范化与渠道化的服务网格开发与运维才干，规范化 Sidecar 与运转时的界说，一起将运维渠道变得愈加规范易用。
路漫漫其修远兮，吾将上下而求索。
项目地址
- GitHub：github.com/cloudwego
- 官网：www.cloudwego.io
