完善部分章节描述

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**，目标是**将微服务治理体系下沉为与业务无关的基础设施**。但是不管微服务治理体系如何演进，一个健壮、高性能、可扩展的微服务框架都是必不可少的。