From d879493c9e8b83c484680bd3fe7edd8b52c642ed Mon Sep 17 00:00:00 2001 From: hitzhangjie Date: Tue, 23 Jan 2024 21:33:50 +0800 Subject: [PATCH] =?UTF-8?q?=E5=AE=8C=E5=96=84=E9=83=A8=E5=88=86=E7=AB=A0?= =?UTF-8?q?=E8=8A=82=E6=8F=8F=E8=BF=B0?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- 2-research/howto-choose-framework.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/2-research/howto-choose-framework.md b/2-research/howto-choose-framework.md index bf34725..6ab1364 100644 --- a/2-research/howto-choose-framework.md +++ b/2-research/howto-choose-framework.md @@ -4,9 +4,9 @@ ## 影响框架选型的因素 -笔者在腾讯工作期间，先后经历了众多的研发框架，C++的就有好几种：ServerBench Plus Plus（简称SPP）、MCP，Go的GoNeat、Going，Java的JavaNeat、Jungle，还有其他语言的。看似很多编程语言都有几种可选项，但是考虑到团队技术栈、业务场景，能达到可用标准的就真的不多了。而这些影响因素，也同样适用于对业界开源框架的选择。 +笔者在腾讯工作期间，先后经历了众多的研发框架，C++的就有好几种：ServerBench Plus Plus（简称SPP）、MCP，Go的GoNeat、Going，Java的JavaNeat、Jungle，还有其他语言的。看似很多编程语言都有几种可选项，但是考虑到团队技术栈、业务场景，能达到可用标准的就真的不多了。而这些影响因素，也同样适用于对开源框架的选择。 -有哪些因素需要考虑呢（排列部分先后）？ +**有哪些因素需要考虑呢？** * 团队技术栈是比较纯粹还是比较多元，未来走势； * 框架可扩展性如何，是否方便定制化； @@ -22,8 +22,8 @@ 一个经过统筹规划、统一设计、支持多语言版本的微服务框架对我们来说更有吸引力，这样工程同学在涉及到服务交接、服务维护时就会简单很多。很庆幸地是，有幸见证了腾讯tRPC微服务框架的诞生，截止现在推广不到半年已经成功支持了10K+个服务实例的稳定运行。 -开发多语言版本的微服务框架，是需要大量的技术人员的投入才可以实现的，腾讯内部也是通过自上而下、自下而上相结合的全面的技术治理才做到的，而不仅仅是微服务框架，还涉及到微服务的整个运营体系。很多企业团队不一定有这个人力和时间来做这个事情。 +开发多语言版本的微服务框架，是需要大量的技术人员的投入才可以实现的，腾讯内部也是通过自上而下为主的全面的技术治理才做到的，而不仅仅是微服务框架，还涉及到微服务的整个运营体系。很多企业团队不一定有这个人力和时间来做这个事情。 有的团队会考虑先用某种语言实现一个相对完整的框架，用它来作为服务端的proxy，然后实现一个多语言版本的相对精简的框架，用来开发业务逻辑处理服务worker。proxy、worker之间可以选择通过共享内存等方式进行通信。通过这种方式简化了开发多个完整多语言框架的工作量。 -微服务治理不断进化，现在进化到了Service Mesh，目标是**将微服务治理体系下沉为与业务无关的基础设施**。但是不管微服务治理体系如何演进，一个健壮、高性能、可扩展的微服务框架都是必不可少的。 +微服务治理不断进化，现在进化到了**Service Mesh**，目标是**将微服务治理体系下沉为与业务无关的基础设施**。但是不管微服务治理体系如何演进，一个健壮、高性能、可扩展的微服务框架都是必不可少的。