开云手机app(中国)官方网站IOS/安卓通用版/手机APP下载

今日头条从内在段子开始，从日均千万，到亿万，再到百亿级，再到千亿级流量，头条APP不停进化，成为一个TMD小巨头之一。本篇文章讲述头条架构的微服务变迁史。今日头条在2015年中期前，使用的开发语言大量接纳了Python和C++以及PHP技术栈。随着系统庞大度，耦合度不停提升，开始向SOA服务化架构演进。

头条的内容公布系统使用了Django框架，一部门后端系统还使用了PHP，这些解释型语言以及相应的服务历程治理存在一些瓶颈，即便通过大家的智慧获得解决，可是整个服务器后端的架构是一个大的单体架构，需要将一部门功效从单体架构中抽取出来。头条微服务架构概览 因此有须要转移为微服务架构。微服务架构具有如下特点：历程解耦易于治理和明白自我包罗部署解耦自动化。

因此，微服务可以与语言层无关，具有较强的接口约束性，高内聚，服务之间的正向相交性。到现在为止，今日头条技术栈，包罗头条、段子产物线开始全部或部门转移到Go语言构建的微服务平台上。

现在部署的微服务数量凌驾几百个，在最岑岭时，QPS凌驾700万，日处置惩罚用户请求凌驾3000亿次，形成现在部署规模较大的GO语言应用。选择Go语言的原因语法简朴，上手快性能高，编译快，开发效率也不低原生支持并发，协程模型是很是优秀的服务端模型，同时也适合网络挪用部署利便，编译包小，险些无依赖因为团队以前用Go 构建过超大流量的后端服务，对其自己的稳定性有信心。再加上头条后端整体服务化的架构革新，所以决议使用 Go 语言构建后端的微服务架构。

2015年6月，今日头条技术团队开始实验使用 Go 重构后端 Feed 流（信息流）服务。期间一边重构，一边迭代现有业务，同时还举行服务拆分，直到2016年6月，Feed 流后端服务大部门迁移到 Go架构上。

由于期间业务增长较快，夹杂服务拆分，因此没有横向对比重构前后的各项指标。实际上切换到 Go 之后，服务整体稳定性和性能都得以大幅提高。微服务架构 对于庞大的服务间挪用，我们抽象出五元组的观点：(From, FromCluster, To, ToCluster, Method)。每一个五元组唯一界说了一类的RPC挪用。

以五元组为单元，我们构建了一整套微服务架构。头条使用 Go 研发了内部的微服务框架：kite，其完全兼容 Thrift协议。以五元组为基础单元，我们在 kite 框架上集成了服务注册和发现，漫衍式负载平衡，超时和熔断治理，服务降级，Method 级此外指标监控，漫衍式挪用链追踪等功效。

现在统一使用 kite 框架开发内部 Go 语言的服务，整体架构支持无限制水平扩展。关于 kite 框架和微服务架构实现细节后续有时机会专门分享，这里主要分享下我们在使用 Go 构建大规模微服务架构中，Go 语言自己给我们带来了哪些便利以及实践历程中我们取得的履历。内容主要包罗并发，性能，监控以及对Go语言使用的一些体会。并发Go 作为一门新兴的编程语言，最大特点就在于它是原生支持并发的。

和传统基于 OS 线程和历程实现差别，Go 的并发是基于用户态的并发，这种并发方式就变得很是轻量，能够轻松运行几万甚至是几十万的并发逻辑。因此使用 Go 开发的服务端应用接纳的就是“协程模型”，每一个请求由独立的协程处置惩罚完成。

比历程线程模型横跨几个数量级的并发能力，而相对基于事件回调的服务端模型，Go 开发思路越发切合人的逻辑处置惩罚思维，因此纵然使用 Go 开发大型的项目，也很容易维护。并发模型Go 的并发属于 CSP 并发模型的一种实现，CSP 并发模型的焦点观点是：“不要通过共享内存来通信，而应该通过通信来共享内存”。这在 Go 语言中的实现就是 Goroutine 和 Channel。

在1978揭晓的 CSP 论文中有一段使用 CSP 思路解决问题的形貌：“Problem: To print in ascending order all primes less than 10000. Use an array of processes, SIEVE, in which each process inputs a prime from its predecessor and prints it. The process then inputs an ascending stream of numbers from its predecessor and passes them on to its successor, suppressing any that are multiples of the original prime.”要找出10000以内所有的素数，这里使用的方法是筛法，即从2开始每找到一个素数就标志所有能被该素数整除的所有数。直到没有可标志的数，剩下的就都是素数。下面以找出10以内所有素数为例，借用 CSP 方式解决这个问题。从上图中可以看出，每一行过滤使用独立的并发处置惩罚法式，上下相邻的并发处置惩罚法式通报数据实现通信。

通过4个并发处置惩罚法式得出10以内的素数表，对应的 Go 语言代码如下： 以上例子体现出 Go 语言开发的两个特点：1. Go 语言的并发很简朴，而且通过提高并发可以提高处置惩罚效率。2. 协程之间可以通过通信的方式来共享变量。并发控制当并发成为语言的原生特性之后，在实践历程中就会频繁地使用并发来处置惩罚逻辑问题，尤其是涉及到网络I/O的历程，例如 RPC 挪用，数据库会见等。下图是一个微服务处置惩罚请求的抽象形貌： 当 Request 到达 GW 之后，GW 需要整合下游5个服务的效果来响应本次的请求，假定对下游5个服务的挪用不存在相互的数据依赖问题。

那么这里会同时提倡5个 RPC 请求，然后等候5个请求的返回效果。为制止长时间的等候，这里会引入等候超时的观点。超时事件发生后，为了制止资源泄漏，会发送事件给正在并发处置惩罚的请求。

在实践历程中，得出两种抽象的模型。· Wait· Cancel Wait和Cancel两种并发控制方式，在使用 Go 开发服务的时候随处都有体现，只要使用了并发就会用到这两种模式。

在上面的例子中，GW 启动5个协程提倡5个并行的 RPC 挪用之后，主协程就会进入等候状态，需要等候这5次 RPC 挪用的返回效果，这就是 Wait 模式。另一中 Cancel 模式，在5次 RPC 挪用返回之前，已经到达本次请求处置惩罚的总超时时间，这时候就需要 Cancel 所有未完成的 RPC 请求，提前竣事协程。Wait 模式使用会比力广泛一些，而对于 Cancel 模式主要体现在超时控制和资源接纳。

在 Go 语言中，划分有 sync.WaitGroup 和 context.Context 来实现这两种模式。超时控制合理的超时控制在构建可靠的大规模微服务架构显得很是重要，不合理的超时设置或者超时设置失效将会引起整个挪用链上的服务雪崩。图中被依赖的服务G由于某种原因导致响应比力慢，因此上游服务的请求都市阻塞在服务G的挪用上。

如果此时上游服务没有合理的超时控制，导致请求阻塞在服务G上无法释放，那么上游服务自身也会受到影响，进一步影响到整个挪用链上各个服务。在 Go 语言中，Server 的模型是“协程模型”，即一个协程处置惩罚一个请求。如果当前请求处置惩罚历程因为依赖服务响应慢阻塞，那么很容易会在短时间内聚集起大量的协程。

每个协程都市因为处置惩罚逻辑的差别而占用差别巨细的内存，当协程数据激增，服务历程很快就会消耗大量的内存。协程暴涨和内存使用激增会加剧 Go 调理器和运行时 GC 的肩负，进而再次影响服务的处置惩罚能力，这种恶性循环会导致整个服务不行用。在使用 Go 开发微服务的历程中，曾多次泛起过类似的问题，我们称之为协程暴涨。

有没有好的措施来解决这个问题呢？通常泛起这种问题的原因是网络挪用阻塞过长。纵然在我们合理设置网络超时之后，偶然还是会泛起超时限制不住的情况，对 Go 语言中如何使用超时控制举行分析，首先我们来看下一次网络挪用的历程。

第一步，建设 TCP 毗连，通常会设置一个毗连超时时间来保证建设毗连的历程不会被无限阻塞。第二步，把序列化后的 Request 数据写入到 Socket 中，为了确保写数据的历程不会一直阻塞，Go 语言提供了 SetWriteDeadline 的方法，控制数据写入 Socket 的超时时间。凭据 Request 的数据量巨细，可能需要多次写 Socket 的操作，而且为了提高效率会接纳边序列化边写入的方式。

因此在 Thrift 库的实现中每次写 Socket 之前都市重新 Reset 超时时间。第三步，从 Socket 中读取返回的效果，和写入一样， Go 语言也提供了 SetReadDeadline 接口，由于读数据也存在读取多次的情况，因此同样会在每次读取数据之前 Reset 超时时间。

分析上面的历程可以发现影响一次 RPC 泯灭的总时间的是非由三部门组成：毗连超时，写超时，读超时。而且读和写超时可能存在多次，这就导致超时限制不住情况的发生。为相识决这个问题，在 kite 框架中引入了并发超时控制的观点，并将功效集成到 kite 框架的客户端挪用库中。并发超时控制模型如上图所示，在模型中引入了“Concurrent Ctrl”模块，这个模块属于微服务熔断功效的一部门，用于控制客户端能够提倡的最大并发请求数。

并发超时控制整体流程是这样的：首先，客户端提倡 RPC 请求，经由“Concurrent Ctrl”模块判断是否允许当前请求提倡。如果被允许提倡 RPC 请求，此时启动一个协程并执行 RPC 挪用，同时初始化一个超时定时器。

然后在主协程中同时监听 RPC 完成事件信号以及定时器信号。如果 RPC 完成事件先到达，则表现本次 RPC 乐成，否则，当定时器事件发生，讲明本次 RPC 挪用超时。这种模型确保了无论何种情况下，一次 RPC 都不会凌驾预界说的时间，实现精准控制超时。

Go 语言在1.7版本的尺度库引入了“context”，这个库险些成为了并发控制和超时控制的尺度做法，随后1.8版本中在多个旧的尺度库中增加对“context”的支持，其中包罗“database/sql”包。性能Go 相对于传统 Web 服务端编程语言已经具备很是大的性能优势。可是许多时候因为使用方式差池，或者服务对延迟要求很高，不得不使用一些性能分析工具去追盘问题以及优化服务性能。

在 Go 语言工具链中自带了多种性能分析工具，供开发者分析问题。· CPU 使用分析· 内部使用分析· 检察协程栈· 检察 GC 日志· Trace 分析工具下图是种种分析方法截图： 在使用 Go 语言开发的历程中，我们总结了一些写出高性能 Go 服务的方法如下：1. 注重锁的使用，只管做到锁变量而不要锁历程2. 可以使用 CAS，则使用 CAS 操作3. 针对热点代码要做针对性优化4. 不要忽略 GC 的影响，尤其是高性能低延迟的服务5. 合理的工具复用可以取得很是好的优化效果6. 只管制止反射，在高性能服务中杜绝反射的使用7. 有些情况下可以实验调优“GOGC”参数8. 新版本稳定的前提下，只管升级新的 Go 版本，因为旧版本永远不会变得更好。下面形貌一个真实的线上服务性能优化例子。这是一个基础存储服务，提供 SetData 和 GetDataByRange 两个方法，划分实现批量存储数据和根据时间区间批量获取数据的功效。

为了提高性能，存储的方式是以用户 ID 和一段时间作为 key，时间区间内的所有数据作为 value 存储到 KV 数据库中。因此，当需要增加新的存储数据时候就需要先从数据库中读取数据，拼接到对应的时间区间内再存到数据库中。对于读取数据的请求，则会凭据请求的时间区间盘算对应的 key 列表，然后循环从数据库中读取数据。

这种情况下，岑岭期服务的接口响应时间比力高，严重影响服务的整体性能。通过上述性能分析方法对于岑岭期服务举行分析之后，得出如下结论：问题点：· GC 压力大，占用 CPU 资源高· 反序列化历程占用 CPU 较高优化思路：1. GC 压力主要是内存的频繁申请和释放，因此决议淘汰内存和工具的申请2. 序列化其时使用的是 Thrift 序列化方式，通过 Benchmark，我们找到相对高效的 Msgpack 序列化方式。分析服务接口功效可以发现，数据解压缩，反序列化这个历程是最频繁的，这也切合性能分析得出来的结论。

仔细分析解压缩和反序列化的历程，发现对于反序列化操作而言，需要一个”io.Reader”的接口，而对于解压缩，其自己就实现了”io.Reader“接口。在 Go 语言中，“io.Reader”的接口界说如下：这个接口界说了 Read 方法，任何实现该接口的工具都可以从中读取一定数量的字节数据。

因此只需要一段比力小的内存 Buffer 就可以实现从解压缩到反序列化的历程，而不需要将所有数据解压缩之后再举行反序列化，大量节约了内存的使用。为了制止频繁的 Buffer 申请和释放，使用“sync.Pool”实现了一个工具池，到达工具复用的目的。

此外，对于获取历史数据接口，从原先的循环读取多个 key 的数据，优化为从数据库并发读取各个 key 的数据。经由这些优化之后，服务的岑岭 PCT99 从100ms降低到15ms。

上述是一个比力典型的 Go 语言服务优化案例。归纳综合为两点：1. 从业务层面上提高并发2. 淘汰内存和工具的使用优化的历程中使用了 pprof 工具发现性能瓶颈点，然后发现“io.Reader”接口具备的 Pipeline 的数据处置惩罚方式，进而整体优化了整个服务的性能。服务监控Go 语言的 runtime 包提供了多个接口供开发者获取当前历程运行的状态。

在 kite 框架中集成了协程数量，协程状态，GC 停马上间，GC 频率，客栈内存使用量等监控。实时收罗每个当前正在运行的服务的这些指标，划分针对各项指标设置报警阈值，例如针对协程数量和 GC 停马上间。另一方面，我们也在实验做一些运行时服务的客栈和运行状态的快照，利便追查一些无法复现的历程重启的情况。

Go编程思维和工程性相对于传统 Web 编程语言，Go 在编程思维上简直带来了许多的改变。每一个 Go 开发服务都是一个独立的历程，任何一个请求处置惩罚造成 Panic，都市让整个历程退出，因此当启动一个协程的时候需要思量是否需要使用 recover 方法，制止影响其它协程。对于 Web 服务端开发，往往希望将一个请求处置惩罚的整个历程能够串起来，这就很是依赖于 Thread Local 的变量，而在 Go 语言中并没有这个观点，因此需要在函数挪用的时候通报 context。

最后，使用 Go 开发的项目中，并发是一种常态，因此就需要格外注意对共享资源的会见，临界区代码逻辑的处置惩罚，会增加更多的心智肩负。这些编程思维上的差异，对于习惯了传统 Web 后端开发的开发者，需要一个转变的历程。关于工程性，也是 Go 语言不太所被提起的点。

实际上在 Go 官方网站关于为什么要开发 Go 语言内里就提到，现在大多数语言今世码量变得庞大之后，对代码自己的治理以及依赖分析变得异常磨难，因此代码自己成为了最贫苦的点，许多庞大的项目到最后都变得不敢去动它。而 Go 语言差别，其自己设计语法简朴，类C的气势派头，做一件事情不会有许多种方法，甚至一些代码气势派头都被界说到 Go 编译器的要求之内。而且，Go 语言尺度库自带了源代码的分析包，可以利便地将一个项目的代码转换成一颗 AST 树。

下面以一张图形象地表达下 Go 语言的工程性： 同样是拼成一个正方形，Go 只有一种方式，每个单元都是一致。而 Python 拼接的方式可能可以多种多样。下面我们再联合Go与内在段子的微服务升级之实录。内在段子Golang DAO内在近段时间迁移了部门API代码到Golang，主要是为了使用Golang中利便的goroutine。

可是开发中许多冗余代码需要重复开发（缺少一个组件能够收敛种种RPC挪用，复用代码，淘汰开发量），同时，又不希望组件使用过多的黑邪术，导致结构庞大，开发维护贫苦。要求希望开发一个组件： * 能够收敛种种RPC挪用，复用代码，淘汰开发量 * 能够使用Golang的goroutine优势，加速数据获取 * 不要使用太多黑邪术，导致结构庞大难于维护假设场景:需要实现一个接口，接受一个段子的Content_id，返回如下数据： * 数据a. 段子基本内容Content → 挪用获取Conent_Info接口 * 数据b. 段子的作者信息User → 挪用获取User_Info接口 * 数据c. 段子的评论信息Comment → 挪用获取Comment_Info接口一、从RPC挪用开始假设场景在golang中的挪用顺序就是：1. 凭据段子ID(Content_id)，并发挪用数据a(基本内容)和数据c(评论信息)2. 凭据a(基本内容)中的作者userid挪用数据b(作者用户信息userinfo)(图1-1)单独看来，这些操作也没什么，可是我们看看完成这个步骤需要的代码：ContentTask = NewContentInfoTask(id=123) CommentTask = NewCommentsListTask(ContentId=123) ParallelExec(ContentTask, CommentTask) // 并行挪用两个任务 // 判断效果是否正确，一堆代码user_id = ContentTask.Response.User_id //获取作者ID UserResp = NewUserTask(user_id).Load() // 再获取作者信息 // 判断效果，一堆代码// 用上面获取的数据打包数据我们看到，代码很是的冗余，而且贫苦在于，这种步骤基本每个接口都市需要举行，完全无法重用。一旦数据有区别，需要多一点或者少一点数据，又需要重新写一个Load历程。许多Copy的代码。

问题一：那我们能否淘汰这种重回信写的代码？二、基本的Dao功效自然的，我们会想到将RPC挪用都收敛到自己所属的实体(Dao)，并建设Dao之间的关联关系，每个RPC对应一个方法（在方法中将数据填充到自身），即(图2-1)：此时，我们获取数据只需要如下代码：content = NewContentDao(id=123) // 段子信息 comments = NewCommentList(ContentId=123) // 段子评论信息 // 第一层Load: 获取Content和comments的信息ParallelExec(content.Content_Info(), comments.Comment_Info()) # 并行两个任务 // 第二层Load: 获取user的属性user = NewUser(id=content.UserId) user.User_Info() // 使用上面临象的属性，举行数据的打包。Python中可以将方法作为property，纵然用某个属性的时候，才举行需要的RPC挪用，使用越发的利便。

可是也就不利便举行并行处置惩罚显然的，此时代码已经省略了许多：将RPC挪用收敛到了一个实体中。更进一步，我们可以使用已经包罗在了Dao关联关系之中的相互关系：即，获取用户和评论信息，是可以通过Dao来挪用的。

content = NewContentDao(id=123) ParallelExec(content.Content_Info(),content.Comments.Comment_Info()) // 并发获取content基本信息和Comment信息 content.User.User_Info() //获取作者信息 至此，已经实现了基本的Dao功效。即：· 收敛所有RPC、DB、Cache等跨服务挪用· 并建设他们之间的关联关系· 收敛冗余代码，只要实现一套Dao(收敛属于该实体的所有挪用)此时要实现新一个接口将是相对轻松的事情！只需要聚合种种Dao之后打包数据即可可是此时，代码就会是一个套路：加载第一层、加载第二层、、、、加载第N层。加载完所有数据之后，再举行打包。问题二：那么我们能否让这种套路自动化？三、自动构建挪用树再次回首我们的Dao的关联关系对应的工具图，可以显着的看到是一个树结构（全树） （图3-1）：而我们需要的是这些属性：Content、User、Comment，即树中的某些节点 （图3-2）：所以，我们需要有某个组件(称之为Loader组件)，使用DAO的挪用方提供需要的属性（即上图中的红色部门），该组件将上图3-2和图3-1的全树举行match，一旦需要，则举行RPC挪用，将效果数据放到Dao工具中。

最终返回一个已经Load好数据的Dao的struct就可以啦！问题三：1. Dao之间有一些庞大的依赖关系，同时一个Dao内的属性又有依赖关系， 这个组件如何组织挪用和对应的先后关系？2. 如何实现挪用中的并发获取？3. 如何（何种形式）告诉这个组件你需要的数据的路径？四、自动并发加载：问题1：组件如何组织挪用和对应的先后关系？在上一节自动构建挪用树中我们已经知道Dao之间的关系。现在我们再将Dao拆开，以RPC挪用为最小的单元，再来看下这个树（图4-1）：白圆圈是每个需要RPC挪用的代码块，白方块表现属性(部门表现由RPC挪用获取到的属性)。

有没有发现什么？我们单独拿Content来看，他的属性结构如下（图4-2）：再联合图4-1，可以看到：1. 一些基本属性如Text、UserId、DiggCount仅仅依赖于主键ID；2. 另外一些属性如：User、Category等，是依赖于1中的基本属性此时，将一个DAO中的所有属性分成两种：· Basic：依赖于主键ID，即获取这个属性，仅仅依赖于主键。· Sub：依赖于Basic中的某个属性。如此划分之后，就可以将Dao拆分成两层挪用： 第一层Basic挪用基本的；完成之后，Sub依赖的属性都具备了，再挪用第二层；至此该Dao的数据加载完成划分之后，每个DAO的属性如下（图4-3）：如content则存在一个属性和RPC挪用关联关系的map：// 基本属性和RPC挪用方法的映射BASIC_LOADER_MAP = map[string]Loader{ "basic": {Loader: duanziBasicLoader}, // 获取段子的基本属性(依赖于content_id) "commentStats": {Loader: commentstatsLoader}, // content的评论数据(依赖于content_id)}// Sub属性和RPC挪用方法的映射SUB_LOADER_MAP = map[string]Loader{ "User": {Loader: userLoader,}, // 作者信息(依赖于段子信息中的user_id)}再建设他们之间的联系（图4-4）：至于下层的Dao的挪用，则交给下层的Dao来完成，当前层不再介入，此时，我们的挪用结构如下(图4-5)：问题2：如何实现挪用中的并发获取？我们只需要在挪用历程中，将同一个层的Basic或者Sub举行并发挪用，就可以了，如（图4-6）：即挪用顺序如下（每行表现一个RPC挪用，并列的行，并行挪用）：1. 设置Content_Id 2. 开启Goroutine，并发挪用Content的Basic层： * a. RPC获取段子基本信息 * b. RPC获取段子Stats * c. 评论Dao， * 1. 评论Dao挪用自身的Basic层 * a. RPC获取评论基本信息 * d. RPC获取评论相关数据stats3. 开启Goroutine，并发挪用Content的Sub层： * a. CategoryDao * 2. Basic层： * a. RPC获取Category信息 * b. UserDao * 1. Basic层： * a. RPC获取用户基本信息 * 2. Sub层： * .......问题3：最后，我们讨论一下问题三的3：如何告诉这个组件你需要的数据的路径？其实上面的结构梳理清楚了，那么这个问题就好解决了， 我们无非是提供一个你需要的属性的树，让Dao的结构一层层遍历的历程中，将该树通报下去， 如果match，则mark一下这个RPC会举行挪用，mark完成当前Dao的basic层和sub层之后，统一并发挪用。而下一级的Dao的Load则在sub层中做，下一级的Dao又去match提供的树，构建自身的Load任务。

如此一层层举行下去，直到Load完所有你需要的属性！好比你需要Contentinfo和Content中的UserInfo和Content中的Comment，就结构一棵树：Content_Info → User_Info → Comment_Info然后通报给该组件，他就能够只Load这几个需要的属性，match和结构以及并发挪用的历程如下：// paramLoaderMap、subLoaderMap是basic和sub属性和Rpc挪用关系的mapfunc DaoLoad(needParamsTree, daoList, paramLoaderMap, subLoaderMap) error { var basicParamTaskList // Basic打包任务列表 var subDaoTaskList // Sub打包任务列表 // 遍历用户需要的属性，结构当前Dao的Basic和Sub任务结构 for _, sonTree := range needParamsTree { if basic属性需要Load { // put to basicParamTaskList } else if sub属性需要load{ // put to subDaoTaskList } } // 并发执行Basic Load // 并发执行Sub Load}优化：1. 组件来资助挪用方建设needParamsTree，只需要提供几个个字符串,：[]string{"Content_Info", "Content.User_Info", "Content.Comment_Info"}，2. 组件帮你填充Sub依赖的基本属性，Sub属性依赖的Basic属性是确定的，可以交给Dao自己来填充，此部门也可以省略。此时我们的代码如下：dao = LoadDao([1,2,3], []string{"User_Info", "Comment_Info"}).Exec() // 用dao去打包数据吧！多个差别类型的Dao的Load就多构建几个并行执行Exec即可此时该组件淘汰了许多冗余的代码，而且能够并发加速Load数据的历程。

以后还能够利便的使用！问题：问：以上面的模型来说，这样显然会带来更多的rpc挪用（好比链条a.获取段子的用户信息；链条b.段子的评论的用户信息无法举行聚合之后再挪用）：答：开始思量过合并淘汰RPC挪用，可是这种方式有时候是有损的，即可能链条a更长，为了等候链条b拿到用户ID，导致了总耗时的增加。所以选择了两者区离开。此时就耗时来说，相对最开始的模型并没有增长，都是取最长路径。无非是相同的RPC挪用会增多，可是这个是可以容忍的。

因为：1. 使用Go，消耗有限，只是多开了一些goruntine而已；2. 凭据业务的情况来看，这种增长有限，在忍受规模内；至此，整个Go_Dao的Load完成(version 1.0)，再回到最开始的配景要求，算是完成基本的要求：· 该组件能够实现基本的Dao的功效（收敛所有RPC、DB、Cache等跨服务挪用，并建设他们之间的关联关系，收敛冗余代码，淘汰开发者的事情量）· 同时能够使用Golang的并行优势加速数据获取· 没有使用Golang中的一些相对庞大的特性(好比反射等)就功效来说，这个组件最好的使用场景在于需要许多跨服务挪用的地方，能够极大的节约开发量。当前还只是第一个版本，还需要连续的迭代。总结今日头条使用 Go 语言构建了大规模的微服务架构。在文前论述了 Go 语言特性，着重解说了并发，超时控制，性能等。

Go 不仅在服务性能上体现卓越，而且很是适合容器化部署。后面我们又分享了内在段子的Go语言微服务化实践。头条内部很大一部门服务已经运行于内部的私有云平台。联合微服务相关组件，向着 Cloud Native 架构演进。

作者：项超。今日头条高级研发工程师。2015年加入今日头条，卖力服务化革新相关事情。

在内部推广Go语言的使用，研发内部微服务框架kite，集成服务治理，负载平衡等多种微服务功效，实现了Go语言构建大规模微服务架构在头条的落地。项超曾就职于小米。

本文来源：开云app官网下载-www.zhongai98.com