腾讯组织架构调整一周年，智慧出行到底都做了些什么？

腾讯成立了技术委员会，旨在加强技术共享的文化与协同。汤道生称，在半年内，腾讯创建了600多个内部开源项目，技术图谱上有近300个项目，并且还在不断增加。“我们最强调的是生态。”在演讲中，刘炽平不断强调腾讯在数字化时代的“助手”角色，数字世界的生态与物理世界的生态在不断趋同，而且越来越紧密地融合在一起。“我们希望做生态的‘共建者’，成为大家的‘帮助者’，而不是传统互联网行业的颠覆者。”刘炽平说。

2019年的夏天，中国科技公司正在遭遇全球性挑战。作为中国互联网科技公司代表之一的腾讯，正在展示他们的思考：技术演化和组织架构调整究竟意味着什么。

这是腾讯启动“930改革”(2018年9月30日腾讯宣布组织架构调整)之后，腾讯发起的第一次大规模会议。刘炽平是腾讯公司总裁，汤道生是腾讯高级执行副总裁、腾讯云与智慧产业事业群(CSIG)总裁。5月21日，他们试图阐述腾讯在互联网下半场所扮演的新角色。

200多天前，作为腾讯公司高级管理顾问、青腾大学教务长的杨国安，深度参与腾讯 “930改革”。作为商学院教授，他的理论在腾讯的转型中得以实践。“产业互联网赛道又大又长，还有得搞。”杨国安5月23日对本报说。

那一次调整，是腾讯历史上第三次大规模组织调整。与前两次不同的是，这次在战略上进行了根本调整，腾讯在深耕ToC基础上，同时向ToB转身。这将是一次从战略到组织管理再到公司文化的变革。

在消费互联网领域已经站在金字塔顶的腾讯，需要一次彻底的变革以激发创新。在通讯技术基础设施不断丰富和普及化之下，迎来了产业互联网。“风来了。”杨国安说。

还不到10年前，腾讯被指为中国互联网世界的“抄袭者”。大家的批评是，“无论你们现在打得多欢实，等市场培育得差不多了，就该轮到腾讯来收场了。”当时美团CEO王兴的一句话广泛传播，“有什么业务是腾讯不做的吗？”

如今，汤道生说，在这个市场上已经有经验丰富的玩家，“腾讯不应该什么都碰，很多领域我们不需要自己去做。”

在2018年组织架构调整后，汤道生被授予了新的使命——掌管腾讯ToB业务的对外窗口CSIG。“CSIG是腾讯ToB业务的对外窗口，其它的事业群则是强大的火力军团，各个事业群会主动找到CSIG，探讨如何将业务对外输出。”汤道生解释。

qq是C/S（Client/Server 客户端/服务器）结构的，我们在计算机上安装的QQ程序就是客户端，服务器就在腾讯公司，我们通过客户端程序访问在腾讯上的服务器。不过，那个Webqq(网页QQ)是通过浏览器访问服务的，所以这个Webqq是属于B/S结构的。 B/S（Browser/Server 浏览器/服务器）比如我们常用的博客，不需要安装客户端程序直接用浏览器访问服务，服务器同样也是架设在相应的公司内部。

UDP协议是无连接方式的协议，它的效率高，速度快，占资源少，但是其传输机制为不可靠传送，必须依靠辅助的算法来完成传输控制。QQ采用的通信协议以UDP为主，辅以TCP协议。由于QQ的服务器设计容量是海量级的应用，一台服务器要同时容纳十几万的并发连接，因此服务器端只有采用UDP协议与客户端进行通讯才能保证这种超大规模的服务。

QQ客户端之间的消息传送也采用了UDP模式，因为国内的网络环境非常复杂，而且很多用户采用的方式是通过代理服务器共享一条线路上网的方式，在这些复杂的情况下，客户端之间能彼此建立起来TCP连接的概率较小，严重影响传送信息的效率。而UDP包能够穿透大部分的代理服务器，因此QQ选择了UDP作为客户之间的主要通信协议。

采用UDP协议，通过服务器中转方式。因此，现在的IP侦探在你仅仅跟对方发送聊天消息的时候是无法获取到IP的。大家都知道，UDP 协议是不可靠协议，它只管发送，不管对方是否收到的，但它的传输很高效。但是，作为聊天软件，怎么可以采用这样的不可靠方式来传输消息呢？于是，腾讯采用了上层协议来保证可靠传输：如果客户端使用UDP协议发出消息后，服务器收到该包，需要使用UDP协议发回一个应答包。如此来保证消息可以无遗漏传输。之所以会发生在客户端明明看到“消息发送失败”但对方又收到了这个消息的情况，就是因为客户端发出的消息服务器已经收到并转发成功，但客户端由于网络原因没有收到服务器的应答包引起的。

很多人提到keepalive，TCP无法感知网络中断这些问题。。。这个算是TCP一个容易踩的坑，但这并不能说明UDP就比TCP好（或者说解释为何要使用UDP）。因为在UDP上面一样需要面对这些问题，而解决这类问题的方法和在TCP上面进行应用层心跳的方法其实没有本质上的区别。而这就是为什么没有接触过这类问题的人会有题主提出的疑惑。

那么为什么呢？最本质上UDP的优势还是带宽的利用。这一切要回归到99~03年的网络状况，当时网络的特点就是接入带宽很窄而且抖动特别厉害。所谓抖动可能是多方面的，例如延时突发性地暴增、也有可能是由于路由层面的变化突然导致路由黑洞，还各种等等等等的问题。TCP因为拥塞控制、保证有序等原因，在这种网络状态上对带宽的利用是非常低的。而且因为网络抖动的原因，应用层心跳超时（一般不依靠keepalive）应用层主动断掉socket之后TCP需要三次握手才能重新建立链接，一旦出现频繁的小抖动就会使得带宽利用更低。而等待四次挥手的时间，也会占用服务器上宝贵的资源。

总结来说，当网络差到一定程度了，TCP的优势反而会成为劣势。

这时候我们再看看UDP在这种情况下的表现。使用UDP对抗网络抖动，说到底就是在应用层比TCP更快地探测和重传，一旦超过一定的时间没有收到回复，客户端可以选择马上重试或者换一个IP：PORT重试（假如你的服务像QQ一样有多个接入），在服务器端则可以果断地断掉socket。而可以应用UDP的时候，往往是你的应用层协议本身已经具备了一定的面向连接的特性。如果你应用层的协议已经达到了一定程度的消息幂等，客户端可以几乎无脑地进行重传，这样就可以尽可能地降低网络抖动的影响，同时也可以尽可能地利用整个带宽。而刚好QQ的协议，就具备类似的特点。

简单来说就是我们可以使用UDP实现一个面向连接协议，这个协议可以很好地适应当时的网络状况和QQ本身的业务。但凡事都有成本，成本就是你的应用层协议本身需要去实现抵抗网络异常带来的问题。例如乱序、例如业务数据的分片和重组、例如网络状态探测等等等等。。。

而现在UDP也应用在很多跨运营商、跨地域、跨机房之间的服务调用当中。原因无它，就是网络烂到一定程度

1 引言

散进散出货物或者称为大宗入出库货物的管理是综合仓库管理的主要内容12。目前，随着信息技术和网络技术的发展，“信息高速公路”建设已在全球拉开序幕，传统的ClientServer简称CS网络应用系统模式在开放性与信息的发布、交流等方面存在很大的局限性，严重影响到仓储管理适应全球性的全方位信息化进程的步伐，CS网络模式已经不适宜用来构建高性能的仓储管理网。Browser／Server 简称B／S 网络结构模式作为传统CS模式的扩展，为仓储管理的建设提供了崭新的技术手段，开辟了网络建设的新途径。本文为克服传统的ClientServer的局限性，提出了基于B／S模式和C／S模式结合策略的仓储管理信息系统的总体结构和实现方法。

2 总体设计

在市场经济改革的大潮中，仓储行业为谋求发展，大量的是外协代管物资的保管。仓库服务的对象是货主，因此整个仓储管理信息系统的出发点应以货主为中心。货主的管理就成为系统设计的关键技巧。在总体设计上考虑到业务的复杂性及繁重的客户端计算，为提高管理效率，加强仓储管理系统与外部信息交互，系统设计采用C／S＋B／S结构，其结构如图1所示。

3 B／S网络模式的结构、工作原理和特点

B／S网络结构模式是基于Intranet的需求而出现并发展的。Intranet是应用TCPIP协议建立的企事业单位内部专用网络，它采用诸如TCPIP、HTTP、SMTP和HTML等Internet技术和标准，能为企事业单位内部交换信息提供服务。同时，它具有连接Internet的功能和防止外界入侵的安全措施。另一方面，由于数据库具有强大的数据存储和管理能力，并且能够动态地进行数据输入和输出，如果把数据库应用于Intranet上，不仅可以实现大量信息的网上发布，而且能够为广大用户提供动态的信息查询和数据处理服务，进而加强企事业单位内部部门之间、上级部门与下级部门之间、企事业单位员工之间、企事业单位与客户之间以及企事业单位与企事业单位之间的信息交流，降低企事业单位的日常工作成本，提高企事业单位的经济效益。

3．1 BS模式的模型结构

BS模式，即浏览器／服务器模式，是一种从传统的二层CS模式发展起来的新的网络结构模式，其本质是三层结构CS模式。

3．2 BS模式的工作原理

在B／S模式中，客户端运行浏览器软件。浏览器以超文本形式向Web服务器提出访问数据库的要求，Web服务器接受客户端请求后，将这个请求转化为SQL语法，并交给数据库服务器，数据库服务器得到请求后，验证其合法性，并进行数据处理，然后将处理后的结果返回给Web服务器，Web服务器再一次将得到的所有结果进行转化，变成HTML文档形式，转发给客户端浏览器以友好的Web页面形式显示出来。

3．3 BS模式的特点

BS模式管理信息系统基本上克服了CS 模式管理信息系统的不足，其主要表现在：

3．3．1系统开发、维护和升级的经济性

对于大型的管理信息系统，软件开发、维护与升级的费用是非常高的，BS模式所具有的框架结构可以大大节省这些费用，同时，BS模式对前台客户机的要求并不高，可以避免盲目进行硬件升级造成的巨大浪费。

3．3．2 BS模式提供了一致的用户界面

BS模式的应用软件都是基于Web浏览器的，这些浏览器的界面都很相似。对于无用户交互功能的页面，用户接触的界面都是一致的，从而可以降低软件的培训费用。

3．3．3 BS模式具有很强的开放性

在BS模式下，外部的用户亦可通过通用的浏览器进行访问。

3．3．4 B／S模式的结构易于扩展

由于Web的平台无关性，BS模式结构可以任意扩展，可以从一台服务器、几个用户的工作组级扩展成为拥有成千上万用户的大型系统。

3．3．5 BS模式具有更强的信息系统集成性

在BS模式下，集成了解决企事业单位各种问题的服务，而非零散的单一功能的多系统模式，因而它能提供更高的工作效率。

3．3．6 BS模式提供灵活的信息交流和信息发布服务

BS模式借助Internet强大的信息发布与信息传送能力可以有效地解决企业内部的大量不规则的信息交流。

4 CS网络模式的结构、工作原理和特点

CS模式是一种两层结构的系统：第一层是在客户机系统上结合了表示与业务逻辑；第二层是通过网络结合了数据库服务器。CS模式主要由客户应用程序、服务器管理程序和中间件三个部分组成。首先，交互性强是CS固有的一个优点。在CS中，客户端有一套完整应用程序，在出错提示、在线帮助等方面都有强大的功能，并且可以在子程序间自由切换。其次，CS模式提供了更安全的存取模式。由于CS配备的是点对点的结构模式，采用适用于局域网、安全性可以得到可靠的保证。而B／S采用点对多点、多点对多点这种开放的结构模式，并采用TCPIP这一类运用于Internet的开放性协议，其安全性只能靠数据服务器上管理密码的数据库来保证。由于CS在逻辑结构上比BS少一层，对于相同的任务，CS完成的速度总比BS快，使得C／S更利于处理大量数据。由于客户端实现与服务器的直接相连，没有中间环节，因此响应速度快。同时由于开发是针对性的，因此，操作界面漂亮，形式多样，可以充分满足客户自身的个性化要求。但缺少通用性，业务的变更，需要重新设计和开发，增加了维护和管理的难度，进一步的业务拓展困难较多。不过此部分内容对于管理制度成熟的仓库企业而言，其困难度并不大。

5 基于BS模式和CS模式结合策略

如上所述，BS在MIS中的一个重要用途即是WEB而目前企业WEB的基本工作模式就是：

①WEB Browser根据用户操作对WEB Server提出访问请求。

②Server将请求分析处理，通过CGI访问DBMS以进行数据的查询统计或事务的提交。

③CGI根据DBMS返回的结果生成HTML文书经过Server向客户的Browser返回结果。

④Browser将HTML结果显示给用户。

上述流程，工作量主要在WEB Server部分，而对该部分的处理目前也有几种方法，有用CGI访问DBMS也有依靠Web Server自身具有数据库处理能力，也有混合访问DBMS，但总的来说，对Web Server端的应用开发能满足我们的要求。

在各个子系统3应用上，我们仍然使用ClientServer方式，在典型的CS数据库应用中，数据的储存管理功能，是由服务器程序独立进行的，并且通常把那些不同的（不管是已知还是未知的）前台应用所不能违反的规则，在服务器程序中集中实现，例如访问者的权限，编号不准重复、必须有客户才能建立定单这样的规则。所有这些，对于工作在前台程序上的最终用户，是“透明”的，他们无须过问（通常也无法干涉）这背后的过程，就可以完成自己的一切工作。在客户服务器架构的应用中，前台程序可以变的非常“瘦小”，麻烦的事情，都交给了服务器和网络。在CS体系下，数据库真正变成了公共、专业化的仓库，受到独立的专门管理。无论你用小型XBASE类数据库，或大型的Oracle 、Sybase类数据库，在客户端你仍然要装实用程序用于数据服务器的信息联系，而同样对于大多数管理类用户则可安装浏览器编制一定的CGI程序甚至利用新出现的JDBC或ASP技术实现与后台数据库的连接。

为此，我们在仓储管理信息系统中的货主物资入出库管理采用CS模式，而在货主库存物资动态信息管理采用BS模式。具体的功能模块和数据库结构参见文献3。

6 结束语

对于企业的BS应用，从当前的技术水平看，特别适用于系统同用户交互量不大的应用，对于需要大量频繁、高速交互的应用系统，采用这种模式并不一定是最好的选择。采用Intranet应用模式并不一定要全部取代传统的ClientServer结构，从某种意义特别是从近期的发展看，二者应用界限并不清晰，而且往往是互相补充、相辅相成的。事实上，企业MIS采用BS模式并不是要求把应用都转到WEB Server上来，而是要根据情况来选择。那么，在应用中新的BS模式就需要能同传统的CS模式结合起来。

企业在选择MIS系统平台模式时，要考虑到BS模式的先进性，也要考虑到CS模式的成熟性，还可以根据企业自身的业务特点，采取CS与BS交叉并用的体系结构。Intranet系统的出现，其技术日益走向成熟，无疑是企业MIS建设的首选模式。但目前情况下，完全抛弃CS技术及其系统结构模式也是不实际的。一方面，原来的系统能满足使用要求的应保留使用；另一方面，CS技术能解决许多目前Intranet系统还不易解决的问题。此外，Intranet系统的优越性表现在对信息的发布、数据的收集、数据共享方面。事实上，只有将主要以数据库为处理对象的统计、分析、控制作为主体的业务处理技术（CS技术）与采用WEB技术的信息查询、发布系统的有机结合，才是仓储管理企业网络化的最佳解决方案。

QQ应该属于 BS模式和CS模式结合策略

C\S： Client\Server (客户端\服务器），客户端，比较直观的就是：软件程序终端，包括我们经常用到的程序；服务器，就不说了

B\S：Browser\Server(浏览器\服务器），浏览器，就是通过网页界面进行交互的终端，浏览器是载体，个人觉得这个模式慢慢成为主流。

微服务¹架构的目标是帮助工程团队更快，更安全，更高质量地交付产品。解耦服务允许团队快速迭代，对系统的其余部分影响最小。

在Medium，我们的技术堆栈始于2012年的单片Nodejs应用程序。我们已经构建了几个卫星服务，但我们还没有制定一个系统地采用微服务架构的策略。随着系统变得越来越复杂并且团队不断发展，我们在2018年初转向了微服务架构。在这篇文章中，我们希望分享我们有效地做到这一点并避免微服务综合症的经验。

首先，让我们花一点时间来思考微服务架构是什么，不是什么。 “微服务”是那些过载和混乱的软件工程趋势之一。这就是我们在Medium认为它是什么：

该定义包括三个微服务设计原则：

Three Principles of Modeling Microservices

当我们对微服务进行建模时，我们应该遵守所有三个设计原则。这是实现微服务架构全部潜力的唯一途径。错过任何一个都会成为反模式。

没有一个目的，每个微服务最终会做太多事情，成长为多个“单片”服务。我们不会从微服务架构中获得全部好处，我们也会支付运营成本。

如果没有松散耦合，对一个服务的更改会影响其他服务，因此我们无法快速安全地发布更改，这是微服务架构的核心优势。更重要的是，紧密耦合引起的问题可能是灾难性的，例如数据不一致甚至数据丢失。

如果没有高凝聚力，我们将最终得到一个分布式单片系统 - 一组混乱的服务，必须同时进行更改和部署才能构建单一功能。由于多个服务协调的复杂性和成本（有时跨多个团队），分布式单片系统通常比集中式单片系统差得多。

与此同时，了解 微服务不是什么 很重要：

在Medium，我们总是在做出重大产品或工程决策时会问“为什么现在？”这个问题。 “为什么？”是一个显而易见的问题，但它假设我们拥有无限的人，时间和资源，这是一个危险的假设。当你想到“为什么现在？”时，你突然有了更多的限制 - 对当前工作的影响，机会成本，分心的开销等等。这个问题有助于我们更好地优先考虑。

我们现在需要采用微服务的原因是我们的Nodejs单片应用程序已经成为多个方面的瓶颈。

首先，最紧迫和最重要的瓶颈是其性能。

某些计算量很大且I / O很重的任务不适合Nodejs我们一直在逐步改进整体应用程序，但事实证明它是无效的。它的低劣性能使我们无法提供更好的产品而不会使已经非常慢的应用程序变慢。

其次，整体应用程序的一个重要且有点紧迫的瓶颈是它会减慢产品开发速度。

由于所有工程师都在单个应用程序中构建功能，因此它们通常紧密耦合。我们无法灵活地改变系统的一部分，因为它也可能影响其他部分。我们也害怕做出重大改变，因为影响太大，有时难以预测。整个应用程序作为一个整体进行部署，因此如果由于一次错误提交导致部署停滞，那么所有其他更改（即使它们完全正常工作）也无法完成。相比之下，微服务架构允许团队更快地发货，学习和迭代。他们可以专注于他们正在构建的功能，这些功能与复杂系统的其余部分分离。更改可以更快地进入生产。他们可以灵活地安全地尝试重大变革。

在我们新的微服务架构中，更改会在一小时内完成生产，工程师不必担心它会如何影响系统的其他部分。该团队还 探索 了在开发中安全使用生产数据的方法²多年来一直是白日梦。随着我们的工程团队的发展，所有这些都非常重要。

第三，单一应用程序使得难以为特定任务扩展系统或隔离不同类型任务的资源问题。

使用单一的单一应用程序，我们必须扩展和缩小整个系统，以满足更多资源需求的任务，即使这意味着系统过度配置用于其他更简单的任务。为了缓解这些问题，我们对不同类型的请求进行分片，以分离Nodejs进程。它们在一定程度上起作用，但不会扩展，因为这些微单一版本的单片服务是紧密耦合的。

最后但同样重要的是，一个重要且即将成为紧迫的瓶颈是它阻止我们尝试新技术。微服务架构的一个主要优点是每个服务都可以使用不同的技术堆栈构建，并与不同的技术集成。这使我们能够选择最适合工作的工具，更重要的是，我们可以快速安全地完成工作。

采用微服务架构并非易事。它可能会出错，实际上会损害工程生产力。在本节中，我们将分享七个在采用早期阶段帮助我们的策略：

有人可能会认为采用新的服务器架构意味着产品开发的长时间停顿以及对所有内容的大量重写。这是错误的做法。我们永远不应该为了建立新的服务而建立新的服务。每次我们建立新服务或采用新技术时，都必须具有明确的产品价值和/或工程价值。

产品价值应以我们可以为用户提供的利益为代表。与在单片Nodejs应用程序中构建值相比，需要一项新服务来提供值或使其更快地交付值。工程价值应该使工程团队更好，更快。

如果构建新服务没有产品价值或工程价值，我们将其留在单一的应用程序中。如果十年内Medium仍然有一个支持某些表面的单片Nodejs应用程序，那就完全没了问题。从单一应用程序开始实际上有助于我们战略性地对微服务进行建模。

建立具有明确价值的新服务

有人可能会认为采用新的服务器架构意味着产品开发的长时间停顿以及对所有内容的大量重写。这是错误的做法。我们永远不应该为了建立新的服务而建立新的服务。每次我们建立新服务或采用新技术时，都必须具有明确的产品价值和/或工程价值。

产品价值应以我们可以为用户提供的利益为代表。与在单片Nodejs应用程序中构建值相比，需要一项新服务来提供值或使其更快地交付值。工程价值应该使工程团队更好，更快。

如果构建新服务没有产品价值或工程价值，我们将其留在单一的应用程序中。如果十年内Medium仍然有一个支持某些表面的单片Nodejs应用程序，那就完全没了问题。从单一应用程序开始实际上有助于我们战略性地对微服务进行建模。

单片持久存储被认为是有害的

建模微服务的很大一部分是对其持久数据存储（例如，数据库）进行建模。跨服务共享持久数据存储通常似乎是将微服务集成在一起的最简单方法，然而，它实际上是有害的，我们应该不惜一切代价避免它。这就是原因。

首先，持久数据存储是关于实现细节的。 跨服务共享数据存储会将一个服务的实现细节暴露给整个系统。如果该服务更改了数据的格式，或者添加了缓存层，或者切换到不同类型的数据库，则还必须相应地更改许多其他服务。 这违反了松散耦合的原则。

其次，持久数据存储不是服务行为，即如何修改，解释和使用数据 。如果我们跨服务共享数据存储，则意味着其他服务也必须复制服务行为。 这违反了高内聚的原则 - 给定域中的行为泄露给多个服务。如果我们修改一个行为，我们将不得不一起修改所有这些服务。

在微服务架构中，只有一个服务应该负责特定类型的数据。所有其他服务应该通过负责服务的API请求数据，或者保留数据的 只读非规范（可能具体化）副本 。

这可能听起来很抽象，所以这是一个具体的例子。假设我们正在构建一个新的推荐服务，它需要来自规范帖子表的一些数据，目前在AWS DynamoDB中。我们可以通过两种方式之一为新推荐服务提供发布数据。

在单片存储模型中，推荐服务可以直接访问单片应用程序所执行的相同持久存储。这是一个坏主意，因为：

缓存可能很棘手。 如果推荐服务与单一应用程序共享相同的缓存，我们也必须在推荐服务中复制缓存实现细节;如果推荐服务使用自己的缓存，当单片应用更新帖子数据时，我们将不知道何时使其缓存无效。

如果单片应用程序决定更改为使用RDS而不是DynamoDB来存储帖子数据，我们将不得不重新实现推荐服务中的逻辑以及访问帖子数据的所有其他服务。

单片应用程序具有解释帖子数据的复杂逻辑 ，例如，如何确定帖子是否应该对给定用户不可见。我们必须在推荐服务中重新实现这些逻辑。一旦整体应用程序更改或添加新逻辑，我们也需要在任何地方进行相同的更改。

即使推荐服务是自己的数据访问模式的错误选项，推荐服务仍然停留在DynamoDB上。

在解耦存储模型中，推荐服务不能直接访问发布数据，也不能直接访问任何其他新服务。发布数据的实​​现细节仅保留在一个服务中。有不同的方法来实现这一目标。

Option A 理想情况下，应该有一个拥有帖子数据的Post服务，其他服务只能通过Post服务的API访问邮政数据。但是，为所有核心数据模型构建新服务可能是一项昂贵的前期投资。

当人员配置有限时，还有一些更实用的方法。根据数据访问模式，它们实际上可能是更好的方式。

在 选项B 中，单一应用程序可让推荐服务知道何时更新相关的帖子数据。通常，这不必立即发生，因此我们可以将其卸载到排队系统。

在 选项C 中，ETL管道生成推荐服务的发布数据的只读副本，以及可能对推荐有用的其他数据。在这两个选项中，推荐服务完全拥有其数据，因此它可以灵活地缓存数据或使用最适合的数据库技术。

解耦“建立服务”和“运行服务”

如果构建微服务很难，那么运行服务往往更难。 当运行服务与构建每个服务相结合时，它会减慢工程团队的速度，团队必须不断重新发明这样做。我们希望让每项服务都专注于自己的工作而不用担心如何运行服务的复杂问题，包括网络，通信协议，部署，可观察性等。服务管理应该与每个服务的实现完全分离。

由于最近在 容器化，容器编排，服务网格，应用程序性能监 控等方面的技术进步，“运行服务”的解耦变得比以往更容易实现。

网络。 网络（例如，服务发现，路由，负载平衡，流量路由等）是运行服务的关键部分。传统方法是为每种平台/语言提供库。它工作但不理想，因为应用程序仍然需要非常繁琐的工作来集成和维护库。通常，应用程序仍然需要单独实现某些逻辑。现代解决方案是在Service Mesh中运行服务。在Medium，我们使用 Istio和Envoy作为边车代理 。构建服务的应用工程师根本不需要担心网络问题。

通信协议 。无论您选择哪种技术堆栈或语言来构建微服务，从一个高效，类型化，跨平台且需要最少开发开销的成熟RPC解决方案开始是非常重要的。支持向后兼容性的RPC解决方案也使部署服务更加安全，即使它们之间存在依赖关系。在Medium，我们选择了gRPC。

一种常见的替代方案是基于HTTP的REST + JSON，它长期以来一直是服务器通信的福音解决方案。但是，尽管该堆栈非常适合浏览器与服务器通信，但它对于服务器到服务器的 通信效率很低 ，尤其是当我们需要发送大量请求时。如果没有自动生成的 存根和样板代码 ，我们将不得不手动实现服务器/客户端代码。可靠的RPC实现不仅仅包装网络客户端。另外，REST是“自以为是”，但总是让每个人都对每个细节都达成一致很困难，例如，这个调用真的是REST，还是只是一个RPC？这是一种资源还是一种操作？等等

部署。 拥有一致的方法来构建，测试，打包，部署和管理服务非常重要。所有Medium的微服务都在容器中运行。目前，我们的编排系统是AWS ECS和Kubernetes的混合体，但仅限于Kubernetes。

我们构建了自己的系统来 构建，测试，打包和部署 服务，称为BBFD。它在一致地跨服务工作和为个人服务提供采用不同技术堆栈的灵活性之间取得平衡。它的工作方式是让每个服务提供基本信息，例如，要监听的端口，构建/测试/启动服务的命令等，BBFD将负责其余的工作。

彻底和一致的可观察性

可观察性包括允许我们了解系统如何工作的过程，约定和工具，以及在不工作时对问题进行分类。可观察性包括日志记录，性能跟踪，指标，仪表板，警报，并且对于微服务架构的成功至关重要。

当我们从单个服务迁移到具有许多服务的分布式系统时，可能会发生两件事：

我们失去了可观察性，因为它变得更难或更容易被忽视。

不同的团队重新发明了轮子，我们最终得到了零碎的可观察性，这实际上是低可观察性 ，因为很难使用碎片数据连接点或分类任何问题。

从一开始就具有良好且一致的可观察性非常重要，因此我们的DevOps团队提出了一致的可观察性策略，并构建了支持实现这一目标的工具。每项服务都会自动获取详细的DataDog仪表板，警报和日志搜索，这些服务在所有服务中也是一致的。我们还大量使用LightStep来了解系统的性能。

并非每一项新服务都需要从零开始构建

在微服务架构中，每个服务都做一件事并且做得非常好。请注意，它与如何构建服务无关。如果您从单一服务迁移，请记住，如果您可以从单片应用程序中剥离微服务并不总是必须从头开始构建。

在这里，我们采取务实的态度。我们是否应该从头开始构建服务取决于两个因素：（1）Nodejs适合该任务的程度如何;（2）在不同的技术堆栈中重新实现的成本是多少。

如果Nodejs是一个很好的技术选项并且现有的实现很好，我们将代码从单片应用程序中删除，并用它创建一个微服务。即使采用相同的实现，我们仍将获得微服务架构的所有好处。

我们的单片Nodejs单片应用程序的架构使我们可以相对轻松地使用现有实现构建单独的服务。我们将在本文稍后讨论如何正确构建单片。

尊重失败，因为他们会发生

在分布式环境中，更多的东西可能会失败，而且它们会失败。如果处理不当，任务关键型服务的失败可能是灾难性的。我们应该始终考虑如何测试故障并优雅地处理故障。

从第一天起避免使用微服务综合症

微服务不是灵丹妙药 - 它解决了一些问题，但创造了一些其他问题，我们将其称为“微服务综合症”。如果我们从第一天开始就不去考虑它们，那么事情会变得很快，如果我们以后再照顾它们会花费更多。以下是一些常见症状。

随着最近的技术创新，采用微服务架构要容易得多。这是否意味着我们都应该停止构建单一服务？

虽然新技术支持得更好，但微服务架构仍然存在高度复杂性和复杂性。 对于小型团队来说，单一的应用程序通常仍然是更好的选择。但是，请花些时间来构建单片应用程序，以便以后在系统和团队成长时更容易迁移到微服务架构。

在Medium，我们在早期的单片应用程序中做出了一些很好的架构决策。

我们的单片应用程序由组件高度模块化，即使它已经发展成为一个非常复杂的应用程序，包括Web服务器，后端服务和离线事件处理器。脱机事件处理器单独运行，但使用完全相同的代码。这使得将一大块业务逻辑剥离到单独的服务相对容易，只要新服务提供与原始实现相同（高级）的接口即可。

我们的整体应用程序在较低级别封装了数据存储详细信息。每种数据类型（例如，数据库表）具有两层实现：数据层和服务层。

这有助于我们采用微服务架构，因为一种类型数据的实现细节完全隐藏在代码库的其余部分。创建新服务来处理某些类型的数据相对容易且安全。

单片应用程序还可以帮助我们对微服务进行建模，并使我们能够灵活地专注于系统中最重要的部分，而不是从头开始为所有微服务建模。

单片Nodejs应用程序为我们服务了好几年，但它开始减慢我们从运送伟大的项目和快速迭代。我们开始系统地和战略性地采用微服务架构。我们仍处于这一旅程的早期阶段，但我们已经看到了它的优势和潜力 - 它大大提高了开发效率，使我们能够大胆地思考并实现大量的产品改进，并解锁了工程团队以安全地测试新技术。

加入Medium的工程团队是一个激动人心的时刻。如果这听起来很有趣，请查看我们的工作页面 - 在Medium工作。如果您对微服务架构特别感兴趣，您可能需要先了解这两个开头：高级全栈工程师和高级平台工程师。

原文 :https://mediumengineering/microservice-architecture-at-medium-9c33805eb74f

讨论: 请加入知识星球首席架构师圈