去年，微服务架构领域发生了几个引人注目的事件。首先，才刚刚接管Twitter的Elon Musk对该平台的开发团队进行了一番“批评”。他对Twitter在许多国家的运行速度缓慢表示抱歉。造成这种情况的原因是应用程序需要执行超过1000个“糟糕”的批处理RPC，而这仅仅是为了渲染主页的时间线。Musk表示：“今天我们将关闭那些庞大的‘微服务’，事实上，Twitter只需要其中不到20%的微服务来运行。”
其次，GitHub前CTO Jason Warner在社交媒体上表示：“我相信，在过去十年里，全面采用微服务是最大的架构错误之一。” “任何有经验构建大型分布式系统的人都知道它们并不真正起作用，但还是得去适应它。”那么，微服务架构是否是一个错误，或者说微服务已经过时了呢？
1.微服务是否必要？
微服务架构的起源可以追溯到2005年，当时Peter Rodgers博士提出了Micro-Web-Service的概念，即将应用程序设计成细粒度的Web服务。然而，微服务的概念真正开始引起广泛关注是在2014年，当时Martin Fowler和James Lewis首次正式提出了微服务的定义。他们将微服务架构描述为一种方法，通过以开发一组小型服务的方式来构建独立的应用系统。每个服务都以独立的进程方式运行，并使用轻量级通信机制（如RPC或HTTP）与其他服务进行通信。这些微服务是围绕业务功能构建的，可以使用不同的编程语言来实现。
微服务的兴起与发展与CICD（持续集成和持续交付）以及基础设施即代码（Infrastructure as Code）的发展有密切关系。这些技术的出现简化了基础设施管理，加快了功能迭代，从而促进了微服务架构的进一步发展和应用。
然而，微服务架构并不是适合所有情况的银弹。尽管微服务可以为业务带来好处，但也会带来一些挑战和副作用。关键在于在适当的时机采用微服务架构，合理决定微服务的拆分粒度，以及选择适当的微服务技术。不应该盲目跟风，也不应该大肆批评微服务的必要性，或者呼吁回到单体架构时代。GitHub的前CTO Jason Warner提出的观点强调了从单体应用向微服务的有序迁移，同时也强调了微服务的数量应该适合组织的规模。他鼓励企业根据自身情况来做出选择，而不是盲目追随潮流。这与前文提到的观点是一致的。微服务架构的成功与否在很大程度上取决于如何明智地应用它，而不是一味地拥护或反对。
（1）在合适的阶段采用微服务架构
根据观察和经验，成功的微服务架构往往是从一个庞大的单体架构逐渐演化而来的。在面对新产品和领域时，很难一开始就完全理解业务需求，通常需要经过一段时间的探索和学习，才能逐步转向微服务架构。此外，在资源有限的情况下，采用微服务架构可能存在一定的风险，特别是当技术选型不当时，可能会凸显出微服务性能方面的劣势。
在划分微服务之前，确保公司内部的基础设施和公共基础服务已经做好准备非常重要。这包括通过监控组件和产品快速定位服务故障、通过工具实现自动化部署和管理服务、通过一站式开发框架降低服务开发成本、通过灰度发布和泳道验证提高服务的可用性、通过资源调度平台快速获取和释放资源以及通过弹性伸缩服务快速扩展应用等方面的能力。这些都是确保微服务架构能够有效运作和发挥优势的关键因素。
（2）合理决定微服务架构的拆分粒度
微服务架构的拆分粒度应当注重合理性，不仅仅追求粒度越小越好或者越多越好。相反，我们需要追求一个适中的粒度。如果粒度过小，微服务架构的缺点将被放大，那么微服务相对于原先的单体架构的弊端将会更加明显。而如果粒度不够细，单体架构的缺点依然存在，同时微服务的优势也无法充分展现，这也是不合理的。
微服务架构的粒度拆分是一项复杂的任务，对于对业务和组织架构理解不深的新人或外部人员来说，很难判断出合理的微服务拆分粒度。
随着业务的发展、组织架构的变化以及团队开发人员水平的提高，微服务架构的粒度可能会发生变化。这是一个持续演进的过程，没有绝对的对错。微服务架构的设计和微服务的拆分应当遵循康威定律，即微服务架构应与产生这些设计的组织架构保持一致，甚至保持动态一致。
当然，仅仅熟悉业务和组织架构是不够的，我们还需要采用合理的微服务拆分策略。例如，对于相对独立的新业务，可以优先考虑采用微服务架构；对于具有通用性的功能，可以优先进行抽象为通用服务；对于边界比较清晰的模块，可以优先进行抽象；对于具有独立属性的服务，也可以优先进行抽象。最后，建议优先抽象核心服务，因为微服务的运维成本较高，并不是所有的地方都需要进行拆分。此外，随着时间的推移，业务可能会发生变化，而核心服务相对来说比较稳定，因此不需要进行过大的调整。
（3）恰当的微服务技术选型
决定采用微服务架构后，选择合适的微服务框架变得至关重要。微服务框架可以封装和抽象分布式场景下常见的通用能力，如负载均衡、服务注册与发现、容错机制以及基本的远程通信能力，从而使开发人员能够快速开发高质量的服务。因此，在采用微服务之前，应该仔细考虑开发语言的选择以及对应微服务框架的选型和试用。
那么，如何才能选择合适的微服务框架呢？我建议从扩展性、易用性、功能丰富度和性能这四个角度进行评估。
首先是扩展性。一个开源框架如果与内部能力紧密耦合、只支持特定场景且无法进行扩展，那么在企业内部定制化的需求下很难应用。因此，选择的框架应该具备良好的扩展性，能够支持各种定制化场景的落地。
其次是易用性。业务开发者希望能够专注于业务开发，而不必过多关注底层框架的细节。因此，选择的框架应该足够简单易用。另一方面，对于基于框架进行二次开发的开发者来说，他们需要框架提供一定程度的定制支持。如果框架的扩展能力过于宽泛导致扩展成本很高，或者可扩展的能力不够多，那么这个框架也会有局限性。
再次是功能丰富度。虽然通过扩展性可以对框架进行定制，但并非所有开发者都有足够的资源和精力进行定制开发。因此，选择的框架应该在自身内部提供不同选择的扩展能力，使开发者能够根据自己的基础设施需求进行组合，并在其所处的环境中运行。
前面三点是在微服务转型初期选择微服务框架时需要重点关注的指标。但随着服务规模和资源消耗的增加，性能问题变得不容忽视。从长远来看，选择框架时必须考虑性能因素，否则后续可能面临框架替换的巨大成本或被迫进行定制优化和维护的问题。
总而言之，微服务并非解决所有问题的银弹，但单体架构同样存在许多缺陷。微服务是在单体架构基础上自然演化而来的一种现代化且云原生的架构，是未来趋势。然而，业务需要在适当的阶段采用微服务架构，并合理决策微服务的拆分粒度以及进行恰当的微服务技术选型。如果过于急躁，服务拆分不合理或技术选型出错，可能会导致架构需要回退到单体架构，这只是个别案例，但我们仍需警惕并引以为戒。
相关内容：微服务及高并发、高可用架构设计与最佳实践
2.如何应对微服务深入发展的挑战？
近十年来，微服务架构在业界掀起了一股热潮。伴随着微服务的兴起，涌现出许多技术创新和开源项目，许多企业也在内部积极推进微服务的落地和推广。以字节跳动为例，该公司在近年内微服务的数量和规模都迎来了快速的发展。2018年，字节跳动的在线微服务数量约为7000-8000个，而到了2021年底，这一数字已经突破了10万个。在企业内部，能够达到如此规模的微服务体系相当罕见，但这也反映出字节跳动在微服务领域取得了深刻的发展。那么，微服务在未来将朝着怎样的方向发展呢？
结合字节跳动服务框架团队的实践经验和业界趋势，我们认为微服务的未来发展将主要集中在安全性提升、稳定性保障、成本优化、为服务治理标准化几个方面。
（1）微服务安全
在微服务架构中，微服务的数量会随着业务的细分和增长而迅速增加。由于这些微服务分布在不同的服务器上，相较于传统的单一平台实现，它们通常会面临更广泛和多样化的潜在攻击风险，这使得及时发现和修复漏洞变得更加复杂。因此，每个微服务都需要对用户进行身份验证和授权，以确保当前访问的用户的身份和权限级别明确。同时，整个系统可能还需要向外部提供服务，如第三方登录授权等。在这种情况下，要求每个微服务都独立实现用户信息管理系统既增加了开发工作量，也增加了出错的风险。因此，统一的身份认证和授权以及支持按需启用 mTLS（双向传输层安全）变得尤为重要。
服务鉴定是一种微服务访问控制能力，它基于身份标识来验证请求的合法性。通过为具体方法或通用方法配置全局开关，可以实现强制身份验证的效果。为了满足合规要求，字节跳动进行了跨业务线数据访问的专项治理。在这一治理中，一个重要前提是实现零信任（Zero Trust）的服务身份，以识别数据请求的可信身份，进一步实现细粒度的访问控制，以满足用户隐私合规要求，确保微服务接口的安全性，以防止类似删库这样的误操作。
严格授权是一种微服务访问控制能力，它基于允许访问列表和不允许访问列表。通过为具体方法或通配方法配置对上游服务的具体集群或通配集群的授权，结合全局开关为开启状态，可以实现严格的访问控制效果。
一些RPC框架本身也具备严格授权的能力，但不同框架的实现方式不一致，难以满足业务的配置需求。字节跳动利用服务网格技术（ByteMesh）实现了统一的严格授权能力，这得益于服务网格技术在字节跳动内部已经全面落地实施。
（2）微服务稳定性
线上服务的稳定性对于互联网应用来说至关重要。如果服务的稳定性不好，将给用户带来不良的使用体验，甚至给企业直接造成经济损失。衡量服务稳定性的一个重要指标是SLO（Service-Level Objectives），它代表了服务可用水平的目标。例如，将服务接口的成功率SLO设定为99.99%，意味着在一周内低于这个基准的不可用时长应该少于X小时，超过X小时就表示该服务的稳定性不达标。通常情况下，微服务的治理能力如超时、重试、容错和限流等可以满足大多数情况需求，并提高微服务的稳定性。在字节跳动内部，我们实现了高水平的微服务化和规模化部署，在精细化的服务治理方面诞生了许多解决方案，如单实例治理和动态过载保护等，进一步提升了微服务的稳定性。
微服务化和大规模分布式部署带来了一定的运维负担，有时候甚至会导致难以区分问题是基础设施问题还是业务自身问题。其中，最常见且通常不需要业务感知的问题是单实例故障导致服务SLA抖动。我们将这类问题统称为单实例问题。单实例问题的成因复杂，涉及到物理和业务等多个方面的因素，几乎无法完全消除。
为了降低对业务的感知程度并提升业务核心服务的服务水平协议（SLA），字节跳动服务框架团队基于服务网格ByteMesh的动态负载均衡能力开发了解决单实例问题抖动的解决方案。该方案通过收集ByteMesh数据面上报的RPC指标（如延迟、错误率）和服务端实例的负载指标（如排队时间、CPU/MEM/IO使用率），动态更新服务端实例的权重，以实现更平均的服务负载效果。这个中心化的控制方案在抖音电商等业务中经过了大规模的验证，有效提高了故障识别的效率。以某个具体的服务为例，当发生单实例故障时，默认配置会在1分钟内执行服务发现的降权或摘除操作，从而将服务不可用时长控制在1分钟以内。同时，我们还提供了单实例治理摘除大盘，方便排查单实例问题。
（3）微服务成本优化
在云原生时代，随着微服务的拆分和增长，微服务过微成为一个不可避免的问题。这导致了额外的延迟和资源消耗等缺点变得更加明显。有人呼吁回归单体架构，但是这并不是解决之道，因为回归单体无法符合业务发展趋势。为了优化微服务的成本，字节跳动探索了许多路径，包括合并部署、JSON序列化优化和开发框架开销优化等。此外，在推进成本优化的背景下，服务框架团队与业务和其他基础团队合作，以挖掘更多性能优化点。
合并部署：字节跳动在微服务架构上进行了深入研究，探索了多种合并部署方案。虽然其他公司也尝试过合并部署，但是现有方案在编译、部署、监控、服务治理和服务隔离等方面对现有体系造成了较大冲击，无法很好地支持现有体系。此外，部署会相互影响，导致协作效率降低。为解决这个问题，基础架构团队提出了一种新的合并部署方案，结合容器亲和性调度、流量调度计算和更高效的本地通信。通过将原本需要跨机进行的网络通信转变为同机进程间调用，该方案既能与现有体系融合，又能减少微服务链路带来的性能损耗。基础架构服务框架团队在QCon 2021上分享了《字节跳动微服务合并部署实践》，引起了其他公司的广泛关注。经过落地测试，合并部署方案在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时，团队借鉴了其他领域/语言的优化思想，并将其融合到各个处理环节中。其中核心技术包括JIT、lazy-load和SIMD。除了上述技术外，sonic还进行了许多细节优化，例如使用RCU替换sync.Map以提升codec缓存的加载速度，使用内存池减少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在公司内部的应用。然而，由于很多功能版本过低，包括Thrift当时只有v0.9.2，这两个框架存在许多问题，同时Golang也迎来了数轮大版本迭代，导致Kite和Ginex在性能和可维护性上存在较大问题。因此，服务框架团队正式启动了Kite的重构，新框架命名为Kitex。这是一个自下而上的整体升级重构，旨在提高性能和可扩展性。类似的设计思路和底层模块也被应用在字节跳动自研的Golang HTTP框架Hertz上，该项目具有高性能和高可扩展性。之后，Kitex和Hertz进入了大规模落地阶段，并持续进行性能和扩展性方面的迭代和优化。2022年，Kitex启动了序列化和Thrift的专项优化，进一步提高了内容拷贝和IO操作的性能开销。
选择适合的Golang微服务框架在选择Golang的前提下非常重要。如前所述，最合适的微服务框架应具备高可扩展性、高易用性、高性能和丰富的内置功能。CloudWeGo就是这样的开源微服务框架和中间件集合，其中包括字节跳动开源的Kitex和Hertz，并且是Golang领域和CNCF Landscape推荐的微服务框架。
（4）微服务治理标准化
微服务架构离不开配套的治理能力。这些治理能力包括服务可观测、全链路压测与灰度、注册发现、配置中心等，它们的实现依赖于服务框架、SDK、Java Agent以及服务网格等技术。随着这些技术的发展，业界出现了各种不同的开发语言、框架和架构，给企业带来了维护负担和技术选型上的困扰。不同框架之间的互通也存在一些问题，如损耗和高复杂度等。不同微服务开发框架和工具链对于服务治理体系的理解和实现也存在差异性，这不利于微服务技术的沉淀和长期发展。为了解决这些问题，终端用户必须在不同的基础设施和适当的工具之间做出抉择，增加了企业在微服务架构落地过程中的成本。
为了应对这个挑战，2022年诞生了两套微服务治理标准化方案。这些方案面向多语言、多框架和异构基础设施，涵盖了流量治理、服务容错、服务元信息治理、安全治理等关键治理领域，提供了一系列的治理能力与标准、生态适配与最佳实践。
在2022年3月，NextArch基金会正式宣布成立微服务SIG。该小组由来自腾讯、字节跳动、七牛云、快手、BIGO、好未来和蓝色光标等多家企业的技术专家组成。该小组致力于推动微服务技术及其开源生态的持续发展。他们将面向企业在微服务生产实践中遇到的问题，为不同行业和应用场景提供标准化解决方案，并与PolatisMesh、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/协议定义服务治理规则，面向多语言异构化架构，覆盖微服务框架及上下游关联组件。
总体而言，微服务治理标准仍处于早期建设阶段。从微服务治理标准定义到控制面的实现，再到各个语言SDK和治理功能的实现，以及微服务生态的整合和落地，都需要进一步的演进和完善。
3.对微服务未来的展望
微服务是一种不断发展的软件架构模式，它并没有解决所有的问题，但也不会过时。尽管微服务在实施过程中存在挑战，但它已经成为云计算基础设施的一部分，和计算、存储、网络、数据库以及安全同等重要。不同阶段的发展给微服务带来了不同的挑战。在云原生普及之前，开发者关注微服务的架构设计、迭代、交付和运维。随着云原生技术的成熟，微服务也开始向云原生化方向发展，这时开发者和架构师更加注重如何利用云计算的优势简化微服务的治理和运维，并提高业务交付效率。选择和迁移高性能的服务框架，标准化微服务治理也成为微服务发展的重要方向。
随着云原生和微服务的发展，高并发、高可用架构设计等技术也将持续受到重视。在这种运营环境中，采用传统的集中式系统架构越来越不能使用未来的发展，整个产业开始向分布式系统转型。然而，在分布式系统转型过程中，有许许多多的分布式技术千差万别，并且要按不同场景去运用不同的分布式技术。为此，中培IT学院将开展微服务及高并发、高可用架构设计与最佳实践培训班，课程理论与实践相结合、案例分析与行业应用穿插进行，通过全面知识理解、专题技能演示和实践引导学员掌握微服务中的核心知识与技术，适合一般软件企业的设计人员和初级架构师,以及资深程序员参与学习。
[1] |
