966,690 十一月 独立访问用户
语言 & 开发
架构 & 设计
文化 & 方法
您目前处于：
分布式 在InfoQ上的内容
演讲所属&分布式
查看所有演讲
迷你书所属&分布式
本次的《中国顶尖技术团队访谈录》·第六季挑选的6个团队虽然都来自互联网企业，却是风格各异。希望通过这样的记录，能够让一家家品牌背后的技术人员形象更加鲜活，让更多人感受到他们的可爱与坚持。
架构 & 设计
文化 & 方法
<及所有内容，版权所有 &#169;
C4Media Inc.
服务器由 提供, 我们最信赖的ISP伙伴。
北京创新网媒广告有限公司
京ICP备号-7
注意：如果要修改您的邮箱，我们将会发送确认邮件到您原来的邮箱。
使用现有的公司名称
修改公司名称为：
公司性质：
使用现有的公司性质
修改公司性质为:
使用现有的公司规模
修改公司规模为：
使用现在的国家
使用现在的省份
Subscribe to our newsletter?
Subscribe to our industry email notices?
我们发现您在使用ad blocker。
我们理解您使用ad blocker的初衷，但为了保证InfoQ能够继续以免费方式为您服务，我们需要您的支持。InfoQ绝不会在未经您许可的情况下将您的数据提供给第三方。我们仅将其用于向读者发送相关广告内容。请您将InfoQ添加至白名单，感谢您的理解与支持。微服务架构下，如何实现分布式跟踪？
&&&&您可以捐助，支持我们的公益事业。
每天15篇文章
不仅获得谋生技能
更可以追随信仰
微服务架构下，如何实现分布式跟踪？
作者：张德阳 来源：极客帮科技 发布于：&
381 次浏览
&&&&评价：
随着互联网技术的高速发展，各种创新技术、前沿概念如雨后春笋般层出不穷，云服务、云计算、大数据处理、大数据分析……，以往单应用的服务架构已经很难处理如山洪般增长的信息数据，随着分布式的普及、服务的快速增长与云计算技术的进步，微服务架构逐渐进入人们的实现，它也因其特有的优势而备受关注。
微服务架构的本质，是把整体的业务拆分成很多有特定明确功能的服务，通过很多分散的小服务之间的配合，去解决更大，更复杂的问题。对被拆分后的服务进行分类和管理，彼此之间使用统一的接口来进行交互。
微服务的特点决定了功能模块的部署是分布式的，以往在单应用环境下，所有的业务都在同一个服务器上，如果服务器出现错误和异常，我们只要盯住一个点，就可以快速定位和处理问题，但是在微服务的架构下，大部分功能模块都是单独部署运行的，彼此通过总线交互，都是无状态的服务，这种架构下，前后台的业务流会经过很多个微服务的处理和传递，我们难免会遇到这样的问题：
分散在各个服务器上的日志怎么处理？
如果业务流出现了错误和异常，如何定位是哪个点出的问题？
如何快速定位问题？
如何跟踪业务流的处理顺序和结果？
我们发现，以前在单应用下的日志监控很简单，在微服务架构下却成为了一个大问题，如果无法跟踪业务流，无法定位问题，我们将耗费大量的时间来查找和定位问题，在复杂的微服务交互关系中，我们就会非常被动。
对于这个问题，业内已经有了一些实践和解决方案，让我们来看看行业内的领先设计思想。
Google Dapper
Google公司广泛使用了分布式集群，为了应对自身大规模的复杂集群环境，Google公司研发了Dapper分布式跟踪系统，并发表了论文《Dapper,
a Large-Scale Distributed Systems Tracing Infrastructure》，给行业内分布式跟踪的实现提供了非常有价值的参考，该论文也成为了当前分布式跟踪系统的理论基础。
我们先来看个例子：
图1 这个路径由用户的X请求发起，穿过一个简单的服务系统。用字母标识的节点代表分布式系统中的不同处理过程。
分布式服务的跟踪系统需要记录在一次特定的请求中系统中完成的所有工作的信息。举个例子，上图展现的是一个与5台服务器相关的一个服务，包括：前端（A），两个中间层（B和C），以及两个后端（D和E）。当一个用户（这个用例的发起人）发起一个请求时，首先到达前端，然后发送两个RPC调用到服务器B和C。B会马上做出反应，但是C需要和后端的D和E交互之后再返还给A，由A来响应最初的请求。对于这样一个请求，简单实用的分布式跟踪的实现，就是为服务器上每一次发送和接收动作来收集跟踪标识符（message
identifiers）和时间戳（timestamped events）。
基于这个模型，Google在此论文中提出了几个重要的概念：
1、 基于标注（annotation-based），又叫植入点或埋点
在应用程序或中间件中明确定义一个全局的标注（annotation），它可以是一个特殊的ID，通过这个ID连接每一条记录和发起者的请求，当然，这需要代码植入，在生产环境中，因为所有的应用程序都使用相同的线程模型，控制流和RPC系统，可以把代码植入限制在一个很小的通用组件库中，从而达到监测系统应用对开发人员的透明。Dapper能够以对应用开发者近乎零侵入的成本对分布式控制路径进行跟踪，几乎完全依赖于少量通用组件库的改造。
当一个线程在处理跟踪控制路径的过程中，Dapper把这次跟踪的上下文在ThreadLocal中进行存储。追踪上下文是一个小而且容易复制的容器，其中承载了Scan的属性比如跟踪ID和span
当计算过程是延迟调用的或是异步的，大多数Google开发者通过线程池或其他执行器，使用一个通用的控制流库来回调。Dapper确保所有这样的回调可以存储这次跟踪的上下文，而当回调函数被触发时，这次跟踪的上下文会与适当的线程关联。在这种方式下，Dapper可以使用trace
ID和span ID来辅助构建异步调用的路径。
Google几乎所有的进程间通信都是建立在一个用C++和Java开发的RPC框架上。我们通过跟踪植入该框架来定义RPC中所有的span。span的ID和跟踪的ID会从客户端发送到服务端。基于RPC的系统被广泛使用在Google中，这是一个重要的植入点。
2、 跟踪树和span
图2：5个span在Dapper跟踪树中的关联关系
在Dapper跟踪树结构中，树节点是整个架构的基本单元，而每一个节点又是对span的引用。节点之间的连线表示的span和它的父span的直接关系。通过简单的parentId和spanId就可以有序地把所有的关系串联起来，达到记录业务流的作用。
Twitter公司的Zipkin
Twitter公司的Zipkin是Google Dapper系统的开源实现，Zipkin严格按照Dapper论文实现，采用Scala编写，并且紧密集成到Twitter公司自己的分布式服务Finagle中，使得跟踪做到对应用透明。
图3：Zipkin应用架构图
Zipkin的整体架构如上图所示，涵盖了信息的收集、处理和展现。
淘宝鹰眼系统（EagleEye）
淘宝鹰眼是基于网络调用日志的分布式跟踪系统，它可以分析网络请求在各个分布式系统之间的调用情况，从而得到处理请求的调用链上的入口URL、应用服务的调用关系，从而找到请求处理瓶颈，定位错误异常的根源位置。同时，业务方也可以在调用链上添加自己的业务埋点日志，使各个系统的网络调用与实际业务内容得到关联。
图4：鹰眼系统的总体架构图
我们的解决方案
针对于微服务，东软平台产品提供了一套完整的微服务解决方案，在此基础上，对微服务架构进行了扩展，基于Google
Dapper的概念，设计了一套基于微服务架构的分布式跟踪系统。
该跟踪系统支持基于dubbo的微服务框架的监控，以及分布式服务调用链跟踪：
图5：东软UniEAP平台基于微服务的分布式跟踪系统流程设计图
分布式跟踪系统的整体流程是通过扩展dubbo作为入口，把监控代码植入到dubbo-filter扩展模块中，然后通过trace-client模块抓取日志数据，存入文件服务器，为了避免产生大量Trace对象造成内存堆积引发的GC问题，trace首先采取写入堆外内存的方式落地，然后通过trace-agent代理模块读取日志信息，给trace-collector收集模块提供日志数据，trace-collector收集模块通过提供统一的接口，为外部获取数据提供支持，可以传输到数据库记录，或者传输给其他的数据分析产品。Trace-web模块作为可视化展示平台，展现服务的完整跟踪链条、心跳监控信息、dubbo原生监控信息，达到数据的展示工作。
除了数据的跟踪以外，该系统还会整合数据分析功能：
图6：集成数据分析功能，提升数据的利用价值
通过集成可视化分析产品，简单的分布式跟踪功能变成了可视化的监控系统，跟踪中产生的数据，会发挥出更大的价值：
1.实时抓取数据，实时分析统计，生成统计和报表
2.可视化的报表系统，更快的了解系统运行状态
3.搜索功能，快速的定位关键问题
4.数据挖据，利用优秀的数据分析能力和数据模型，进行数据预测
分布式跟踪系统应用展望
在分布式场景越来越普及的今天，分布式跟踪将作为微服务必备的基础组件存在，完善的跟踪系统可以极大的提高开发和运维的效率，是企业应用发展不可获缺的组成部分，特别是以下几点：
1、业务流调用流程跟踪
分布式系统的所有日志信息可以通过完善的跟踪串联起来，使系统的运维更加稳定，定位问题更加准确。
2、可视化的监控界面
通过分布式跟踪系统的可视化监控页面，避免了去服务器上查看日志的烦恼。
3、业务分析
在使用了分布式跟踪系统后，我们可以快速的梳理每个调用链路，分析耗时过长的业务是如何产生的，并且可以定位性能不佳的调用片段，合理的分析问题，为性能优化提供非常有价值的参考意见。
更多课程...&&&
更多咨询...&&&
每天2个文档/视频
扫描微信二维码订阅
订阅技术月刊
获得每月300个技术资源
|&京ICP备号&京公海网安备号华为内部如何实施微服务架构？基本就靠这5大原则
运维派推荐
运维派问答社区是专注于IT运维领域的学习、交流、互助的平台，这是属于IT运维人自己的技术社区。
> 华为内部如何实施微服务架构？基本就靠这5大原则
1群： - 运维综合
2群： - 运维综合
3群：1689067
- Linux Shell脚本
微信：yunweipai（或扫描以下二维码）
随着业务的发展，代码量的膨胀和团队成员的增加，传统单体式架构的弊端越来越凸显，严重制约了业务的快速创新和敏捷交付。为了解决传统单体架构面临的挑战，先后演进出了SOA服务化架构、RPC框架、分布式服务框架，最后就是当今非常流行的微服务架构。
微服务化架构并非银弹，它的实施本身就会面临很多陷阱和挑战，涉及到设计、开发、测试、部署、运行和运维等各个方面，一旦使用不当，则会导致整个微服务架构改造的效果大打折扣，甚至失败。
本文从微服务的生命周期全过程，阐述微服务架构的改造如何实施，以及如何避开各种陷阱，提升实施效率。 注：本文内容是华为近几年来的服务化经验分享实录，如果你看的不酸爽，可以直接调到文末报名我们的线下活动，9月华为的同学会做一个线下的workshop，限额80人！
在实施微服务架构改造之前，我们的产品线遇到一个很大挑战，就是需求的交付周期越来越短，采用的传统MVC单体架构越来越难满足特性快速交付和上线的需求。传统的电信项目，团队规模往往都非常大，甚至会跨地域。跨团队、跨地域的分布式协同开发，代码的重用和共享是个难题。
例如我们的支付功能需要新增一个限额保护， 短短十几行代码的一个小需求，评估之后竟然需要9个星期才能上线。原因就是限额保护功能需要同时在9个不同的功能模块中修改， 新增900多个测试用例用来做全量的回归测试，示例如下：
通过对已有的MVC单体架构进行分析，我们发现主要存在如下几个问题：
研发成本高：代码重复率高，需求变更困难，无法满足新业务快速上线和敏捷交付。
测试、部署成本高：业务运行在一个进程中，因此系统中任何程序的改变，都需要对整个系统重新测试并部署。
可伸缩性差：水平扩展只能基于整个系统进行扩展，无法针对某一个功能模块按需扩展。
可靠性差：某个应用BUG，例如死循环、OOM等，会导致整个进程宕机，影响其它合设的应用。
代码维护成本高：本地代码在不断的迭代和变更，最后形成了一个个垂直的功能孤岛，只有原来的开发者才理解接口调用关系和功能需求，新加入人员或者团队其它人员很难理解和维护这些代码。
依赖关系无法有效管理：服务间依赖关系变得错踪复杂，甚至分不清哪个应用要在哪个应用之前启动，架构师都不能完整的描述应用的架构关系。
以上问题的应对策略，就是服务化。
首先，需要对业务进行拆分。当业务量大了以后，特别是当不同的功能耦合在一起的时候，任何一个地方的改动都是非常困难的，必须对业务进行拆分，拆分的策略有两种：
横向拆分。按照不同的业务域进行拆分，例如订单、商品、库存、号卡资源等。形成独立的业务领域微服务集群。
纵向拆分。把一个业务功能里的不同模块或者组件进行拆分。例如把公共组件拆分成独立的原子服务，下沉到底层，形成相对独立的原子服务层。这样一纵一横，就可以实现业务的服务化拆分。
其次，要做好微服务的分层：梳理和抽取核心应用、公共应用，作为独立的服务下沉到核心和公共能力层，逐渐形成稳定的服务中心，使前端应用能更快速的响应多变的市场需求。
完成服务的拆分和分层工作之后，就会涉及到分布式的部署和调用。如何透明化、高效的发现服务，需要一个服务注册中心，通过服务化和订阅、发布机制对应用调用关系解耦，支持服务的自动注册和发现。
服务化架构的演进历史
在实施微服务架构之前，我们一起回顾下服务化架构的演进历史。
MVC架构大部分人都用过，它主要用来解决前后端、界面、控制逻辑和业务逻辑分层问题。比较流行的技术堆栈就是Spring + Struts + iBatis（Hibernate）+ Tomcat（JBoss）。
随着业务特别是互联网的发展，业务规模的扩大，模块化逐步成为一种趋势，此时解决模块之间远程调用的RPC框架应运而生。RPC需要解决模块之间跨进程通信的问题，不同的团队开发不同的模块，通过一个RPC框架实现远程调用，RPC框架帮业务把通信细节给屏蔽掉，但是RPC框架也有自身的缺点。
RPC本身不负责服务化，例如：服务的自动发现不管、服务的应用和发布不管、服务的运维和治理也不管。没有透明化、服务化的能力，对整个应用层的侵入还是比较深的。
SOA服务化架构，企业级资产重用和异构系统间的集成对接，SOA架构的现状：在传统企业IT领域，主要是解决异构系统之间的互通和粗粒度的标准化（WebService）。互联网领域，提供一套高效支撑应用快速开发迭代的服务化架构。例如各个互联网公司自研或者开源的分布式服务框架。
微服务架构
首先看一下微服务架构的定义：微服务（MSA）是一种架构风格，旨在通过将功能分解到各个离散的服务中以实现对解决方案的解耦。它有如下几个特征：
小，且只干一件事情。
独立部署和生命周期管理。
轻量级通信，RPC或者Restful。
微服务架构的拆分原则
微服务架构的实施过程中，首先遇到的最大的难题，就是它的拆分原则。
微服务拆分原则：围绕业务功能进行垂直和水平拆分。大小粒度是难点，也是团队争论的焦点。
不好的实践
以代码量作为衡量标准，例如500行以内。
拆分的粒度越小越好，例如以单个资源的操作粒度为划分原则。
建议的原则
功能完整性、职责单一性。
粒度适中，团队可接受。
迭代演进，非一蹴而就。
API的版本兼容性优先考虑。
代码量多少不能作为衡量微服务划分是否合理的原则，因为我们知道同样一个服务，功能本身的复杂性不同，代码量也不同。还有一点需要重点强调，在项目刚开始的时候，不要期望微服务的划分一蹴而就。
微服务架构的演进，应该是一个循序渐进的过程。在一个公司、一个项目组，它也需要一个循序渐进的演进过程。一开始划不好，没有关系。当演进到一个阶段时，微服务的部署、测试和运维等成本都非常低的时候，这对于你的团队来说就是一个好的微服务。
微服务架构的开发原则
微服务的开发还会面临依赖滞后的问题。例如：A要做一个身份证号码校验，依赖服务提供者B。由于B把身份证号码校验服务的开发优先级排的比较低，无法满足A的交付时间点。A会面临要么等待，要么自己实现一个身份证号码校验功能。
以前单体架构的时候，大家需要什么，往往喜欢自己写什么，这其实是没有太严重的依赖问题。但是到了微服务时代，微服务是一个团队或者一个小组提供的，这个时候一定没有办法在某一个时刻同时把所有的服务都提供出来，“需求实现滞后”是必然存在的。
一个好的实践策略就是接口先行，语言中立，服务提供者和消费者解耦，并行开发，提升产能。无论有多少个服务，首先需要把接口识别和定义出来，然后双方基于接口进行契约驱动开发，利用Mock服务提供者和消费者，互相解耦，并行开发，实现依赖解耦。
采用契约驱动开发，如果需求不稳定或者经常变化，就会面临一个接口契约频繁变更的问题。对于服务提供者，不能因为担心接口变更而迟迟不对外提供接口，对于消费者要拥抱变更，而不是抱怨和抵触。要解决这个问题，一种比较好的实践就是管理 + 技术双管齐下：
允许接口变更，但是对变更的频度要做严格管控。
提供全在线的API文档服务（例如Swagger UI），将离线的API文档转成全在线、互动式的API文档服务。
API变更的主动通知机制，要让所有消费该API的消费者能够及时感知到API的变更。
契约驱动测试，用于对兼容性做回归测试。
微服务架构的测试原则
微服务开发完成之后需要对其进行测试。微服务的测试包括单元测试、接口测试、集成测试和行为测试等，其中最重要的就是契约测试：
用微服务框架提供的Mock机制，可以分别生成模拟消费者的客户端测试桩和提供者的服务端测试桩，双方可以基于Mock测试桩对微服务的接口契约进行测试，双方都不需要等待对方功能代码开发完成，实现了并行开发和测试，提高了微服务的构建效率。基于接口的契约测试还能快速的发现不兼容的接口变更，例如修改字段类型、删除字段等。
微服务架构的部署原则
测试完成之后，需要对微服务进行自动化部署。微服务的部署原则：独立部署和生命周期管理、基础设施自动化。需要有一套类似于CI/CD的流水线来做基础设施自动化，具体可以参考Netflix开源的微服务持续交付流水线Spinnaker：
最后一起看下微服务的运行容器：微部署可以部署在Dorker容器、PaaS平台（VM）或者物理机上。使用Docker部署微服务会带来很多优先：
一致的环境，线上线下环境一致。
避免对特定云基础设施提供商的依赖。
降低运维团队负担。
高性能接近裸机性能。
相比于传统的物理机部署，微服务可以由PaaS平台实现微服务自动化部署和生命周期管理。除了部署和运维自动化，微服务云化之后还可以充分享受到更灵活的资源调度：
云的弹性和敏捷。
云的动态性和资源隔离。
微服务架构的治理原则
微服务部署上线之后，最重要的工作就是服务治理。微服务治理原则：线上治理、实时动态生效。
微服务常用的治理策略：
流量控制：动态、静态流控制。
服务降级。
超时控制。
优先级调度。
流量迁移。
调用链跟踪和分析。
服务路由。
服务上线审批、下线通知。
SLA策略控制。
微服务治理模型如下所示：
最上层是为服务治理的UI界面，提供在线、配置化的治理界面供运维人员使用。SDK层是提供了微服务治理的各种接口，供服务治理Portal调用。最下面的就是被治理的微服务集群，集群各节点会监听服务治理的操作去做实时刷新。例如：修改了流控阈值之后，服务治理服务会把新的流控的阈值刷到服务注册中心，服务提供者和消费者监听到阈值变更之后，获取新的阈值并刷新到内存中，实现实时生效。由于目前服务治理策略数据量不是特别大，所以可以将服务治理的数据放到服务注册中心（例如etcd/ZooKeeper），没有必要再单独做一套。
微服务最佳实践
介绍完微服务实施之后，下面我们一起学习下微服务的最佳实践。
服务路由：本地短路策略。关键技术点：优先调用本JVM内部服务提供者，其次是相同主机或者VM的，最后是跨网络调用。通过本地短路，可以避免远程调用的网络开销，降低服务调用时延、提升成功率。原理如下所示：
服务调用方式：同步调用、异步调用、并行调用。一次服务调用，通常就意味着会挂一个服务调用线程。采用异步调用，可以避免线程阻塞，提升系统的吞吐量和可靠性。但是在实际项目中异步调用也有一些缺点，导致使用不是特别广泛：
需要写异步回调逻辑，与传统的接口调用使用方式不一致，开发难度大一些。
一些场景下需要缓存上下文信息，引入可靠性问题。
并行调用适用于多个服务调用没有上下文依赖，逻辑上可以并行处理，类似JDK的Fork/Join, 并行服务调用涉及到同步转异步、异步转同步、结果汇聚等，技术实现难度较大，目前很多服务框架并不支持。采用并行服务调用，可以把传统串行的服务调用优化成并行处理，能够极大的缩短服务调用时延。三种服务调用方式的原理图如下：
微服务故障隔离：线程级、进程级、容器级、VM级、物理机级等。关键技术点：
支持服务部署到不同线程/线程池中。
核心服务和非核心服务隔离部署。
为了防止线程膨胀，支持共享和独占两种线程池策略。
谈到分布式，就绕不开事务一致性问题：大部分业务可以通过最终一致性来解决，极少部分需要采用强一致性。
具体的策略如下：
最终一致性，可以基于消息中间件实现。
强一致性，使用TCC框架。服务框架本身不会直接提供“分布式事务”，往往根据实际需要迁入分布式事务框架来支持分布式事务。
微服务的性能三要素：
I/O模型，这个通常会选用非堵塞的，Java里面可能用java原生的。
线程调度模型。
序列化方式。
公司内部服务化，对性能要求较高的场景，建议使用异步非阻塞I/O（Netty） + 二进制序列化（Thrift压缩二进制等） + Reactor线程调度模型。
最后我们一起看下微服务的接口兼容性原则：技术保障、管理协同。
制定并严格执行《微服务前向兼容性规范》，避免发生不兼容修改或者私自修改不通知周边的情况。
接口兼容性技术保障：例如Thrift的IDL，支持新增、修改和删除字段、字段定义位置无关性，码流支持乱序等。
持续交付流水线的每日构建和契约化驱动测试，能够快速识别和发现不兼容。
李林锋，2007年毕业于东北大学，2008年加入华为，从事电信软件的架构设计和开发。8年Java NIO通信框架、网关平台和中间件设计和开发经验，精通Java NIO、Netty和Mina等NIO通信框架，《Netty权威指南》作者，目前从事云平台相关的架构设计和开发。、
文章出处：聊聊架构（公众号ID :archtime）
转载请注明： &
与《华为内部如何实施微服务架构？基本就靠这5大原则》相关的文章.
长微博分享
博主暂未提供此篇文章的长微博，请联系站长。
二维码分享
打开微信（或者其他社交APP），选择“发现”，进入“扫一扫”拍摄即可。966,690 十一月 独立访问用户
语言 & 开发
架构 & 设计
文化 & 方法
您目前处于：
在InfoQ上的内容
盘点ArchSummit北京站全明星出品人阵容！附议题提交全攻略
ArchSummit全球架构师峰会是由极客邦InfoQ中国团队推出的面向高端技术管理者、架构师的技术大会，北京站即将在12月2日-3日在国际会议中心举行。
敏捷和架构设计分道而行，又最终拥抱彼此成为朋友
在过去很长的一段时间里，由于对敏捷宣言的错误解读，人们认为架构设计和敏捷流程相冲突，敏捷和架构设计分其道而行之。后来，通过实践以及对敏捷真正的理解，大家认识到架构设计对敏捷的重要性，敏捷和架构最终成为朋友。
移动化浪潮下，谈谈多端优化以及延缓架构腐化
不知不觉移动的发展早已是驱动大量技术升级的主要力量，民众已然享受到移动化时代给生活带来的各种便利：购物、饮食、打车、转账等等，然而开发者却面临着移动端的诸多考验：多分辨率适应、不同网络环境的加载优化、Web和Native之争、移动安全等等，并且加上移动技术的日新月异和快速更迭，大量开发者被新需求和新技术冲击下找不着前进方向。
Zeppelin：用于区块链应用的开源安全智能合约架构
开源项目Zeppelin作为一个旨在自动化执行任务和协议的智能合约架构，其目标是提供一个用于审核代码并确保代码安全的社区驱动框架。鉴于以太坊是最广为使用的智能合约开发平台，Zeppelin项目在初期是侧重于为Solidity语言构建工具。在近期发布的Zeppelin路线图建议中，给出了对期望功能模块的具体描述。
微服务架构之外的选择——基于服务架构
来自ThoughtWorks的主管Neal Ford在最近的一次演讲中表达了他对企业软件系统架构转型的看法，他认为从单体架构转向基于服务的架构要比转向微服务架构来得容易。Ford在UberConf 2016大会上做了一次关于基于服务架构的演讲，基于服务架构是介于面向服务架构和微服务架构之间的一个中间地带。
定义万物智能的大脑平台，让AI无处不在
地平线机器人，作为全球瞩目的人工智能初创企业之一，其目标就是让地球上超过1000种设备具有从感知、交互、理解到决策的智能，就像Intel是个人电脑时代的标杆企业一样，成为“人工智能时代的Intel”。
用于Microsoft Azure BaaS的Bletchley项目第一版发布
为在日益增长的区块链联盟市场中占据先机，微软近期推出了Bletchley项目，进一步丰富了它的区块链即服务（BaaS）生态系统。Bletchley是基于以太坊的区块链联盟，旨在更加便捷和安全地构建区块链联盟。
巨建华：巨头与传统金融战争方始，FinTech还须技术路径破局
伴随FinTech的火热，华尔街仿佛即将成为第二个硅谷，国内外越来越多的巨头和创业团队致力于区块链、大数据风控、智能投顾等技术的研究和实践，我们能看到金融业正在自下而上地发生剧烈变革，那么面对这场风口，传统金融将何去何从，创业团队如何寻找破局的机会？
重构和代码异味——通往更整洁的代码
重构可以让代码更整洁，更易于理解和维护。代码异味的辨别需要实践和经验：设计不良的表征说明代码存在更深层次的问题。工具可以帮助我们逐步重构，并防止破坏代码。
IBM推出了针对区块链部署的云服务
近来，IBM推出了针对区块链部署的云服务，该服务构建于IBM的LinuxONE平台之上，有一系列处理区块链的底层服务。Everledger是使用了IBM区块链服务的组织之一，他们的首席执行官称区块链服务提高了其快速前进的能力。IBM也在自己内部的金融链上使用了这一服务，期望能通过区块链技术，缩短其金融纠纷的数目和每件纠纷的处理时间。
微服务意味着分布式系统
Sander Hoogendoorn认为，向微服务迁移就意味着向分布式系统进行迁移，在这里，我们必须要处理延迟、认证与授权、无法到达的消息。通过使用微服务，我们能够将大型系统拆分为更小的组件，从而实现对架构的重新掌控。
Monoliths的分类
Derek Ashmore详细介绍了他所归纳的monoliths的几种类型，他还分享了如何将其分解为更多的管理组件或是微服务。
技术创业杀出血海，亟需成熟期权制度
有的创业如Google、Facebook从一个页面发展成一个帝国，有的创业如Secret、MySpace经过多轮融资或被收购最终成为典型失败的教科书案例。在中国目前似乎仍是创业的最好时代，一方面政策仍鼓励万众创业，另一方面更发达的云计算等技术使创业门槛大大降低，于是创业者们纷纷思量如何嗅到下个爆发式增长的机会，而在创业圈子里，以技术出身的创业者往往能够更进一步，他们相对能更容易地把自己的创意、想法借助自身本领和风口实现出来。
雅虎开源发布/订阅消息平台Pulsar
雅虎发布了其发布-订阅消息平台Pulsar，这个平台在他们内部已经用在了多项服务的生产环境之中。
& 加载更新的 新闻
加载更多 新闻 &
架构 & 设计
文化 & 方法
<及所有内容，版权所有 &#169;
C4Media Inc.
服务器由 提供, 我们最信赖的ISP伙伴。
北京创新网媒广告有限公司
京ICP备号-7
注意：如果要修改您的邮箱，我们将会发送确认邮件到您原来的邮箱。
使用现有的公司名称
修改公司名称为：
公司性质：
使用现有的公司性质
修改公司性质为:
使用现有的公司规模
修改公司规模为：
使用现在的国家
使用现在的省份
Subscribe to our newsletter?
Subscribe to our industry email notices?
我们发现您在使用ad blocker。
我们理解您使用ad blocker的初衷，但为了保证InfoQ能够继续以免费方式为您服务，我们需要您的支持。InfoQ绝不会在未经您许可的情况下将您的数据提供给第三方。我们仅将其用于向读者发送相关广告内容。请您将InfoQ添加至白名单，感谢您的理解与支持。