javascript协程,js 协程

如何利用Node.js 构建分布式集群

那么到底是如何实现服务端调用解耦的呢？在实现方案中，我们采用了（Node.js + Protocol Buffers + Zookeeper + RabbitMQ）的组合，从而实现配置集中化管理：

1.Node.js，主要用于开发业务逻辑。

作为天生的异步脚本语言，Node.js 使用事件驱动、 非阻塞I/O模型大大提升了研发效率，非常适合在分布式设备上运行的数据密集型的实时应用。

我们通过 Fibers库采用协程的方式来解决Node.js 异步编程匿名回调问题，将异步回调逻辑转化为同步，同时也满足了程序员使用同步方法编写异步程序的情怀。

可参考官方介绍：

2.Protocol Buffers，用于强约束消息定义。

Protocol Buffers一种数据交换的格式，它独立于语言，独立于平台。由于它是一种二进制的格式，相比XML和JSON，传输效率会更高，可以将它用于分布式应用之间的数据通信或者异构环境下的数据交换。我们主要将Protocol Buffers用来模版化定义消息结构。

可参考：

3.Zookeeper，实现配置集中管理。

Zookeeper分布式服务框架是Apache Hadoop 的一个子项目，简单的说，Zookeeper=文件系统+通知机制。它主要是用来解决分布式应用中经常遇到的一些数据管理问题，如：统一命名服务、状态同步服务、集群管理、分布式应用配置项的管理等。

我们使用ZooKeeper看重的是它不仅支持集群高可用，还支持持久化节点、临时节点存储和节点变更监控的特点，主要使用了它提供的命名服务、配置管理和集群管理服务。其中，临时节点特性用以实现名字服务注册，节点变更监控实现配置集中管理。

参考：

4.RabbitMQ，实现异构通讯服务间的解耦。

Rabbitmq是一种应用程序对应用程序的通信方法，选择RabbitMQ的原因在于它可以支持集群高可用、简单易用、性能出色和完善的管理工具（如：Web ui / Rest API ）的特点。

使用Rabbitmq中间件服务端实现解耦，其中主要是利用（ Work Queue + Topics Exchange ）来实现后端的无缝扩容，并采用Publish/Subscribe + RPC 实现调用解耦，并利用MQ 统一输入输出。

参考：

走过的一些坑

最后，总结经验避免犯同样的错，是非常重要的，还有一些技术遗留问题，需要我们自行避开这些坑。以下是我们在构建RPC框架过程中遇到的一些坑：

异步编程效率问题(Fibers) Node.js 内存泄漏问题

在复杂在构建复杂应用的时候，很多地方都可能发生内存泄露，也需要考虑异步编程效率问题。为解决这两个问题，我们目前主要采取以下三个手段来解决：

a) 框架封装所有网络通信，业务方只关注业务逻辑、提高研发效率；

b)通过Fibers 封装所有异步函数调用转换为同步方法；

c)谨慎选择第三方库。

异步框架中日志跟踪

异步程序记录日志乱序不利于跟踪业务逻辑调用路径。为解决这个问题，我们通过包装 Fibers 对每一个 Fiber 实例进行编号，在所有日志输出中打印 Fiber id 记录异步调用路径，并配合跨模块会话编号实现请求调用跟踪，以此解决日志纪录的无序问题。

RabbitMQ HA 高可用问题

如果需要实现RabbitMQ HA 高可用特性，有两种途径可以实现：Server 端 HA 和 Client HA。Server 端的高可用性可使用 LVS 或 HAProxy来实现，Client 端的高可用性也是一种选择，这样可以减少架构复杂度和层次依赖。值得注意的是，实现高可用特性时，要记得开启Queue 高可用配置。

()

RabbitMQ HA 网络闪断导致节点分区问题

网络不稳定导致RabbitMQ HA 网络闪断，进而导致节点分区问题。针对这个问题，需要添加对 /api/nodes 进行监控，并及时处理分区问题。

具体的解决方法可参考：

ZooKeeper Session Expired

针对ZooKeeper 会话过期问题，需要大家特别关注处理Zookeeper 集群断开后的重连处理，因为如果重连逻辑没有处理好的话，所有依赖ZooKeeper的特性都将不可用。

具体解决方法可参考：

结 语

经过应用实践，目前看来 Node.js几乎可以做到其他后端语言所能做到所有的事情，ES6特性正式发布如今有人已经开始高喊“javascript: The World's Best Programming Language”，但我也并不认为整个后端完全用Node.js来实现会是一个很好的方案。

本文中提到了Node.js的诸多优点，如异步、非阻塞和事件驱动等，但其也存在一些缺点，如默认单进程单线程不能利用多核，脚本弱类型容易出现运行时BUG，同时因为它简单易用，也导致了代码质量不易控制，对开发人员也提出了更高的要求。所以，就个人经验来看，建议偏复杂业务逻辑控制使用Node.js，如果是偏极致性能的业务建议和C++等其他方案结合使用。

c#coroutine怎么实现

在C#中直接有Thread这个线程，但是在unity中有些元素是不能操作的。这个时候可以使用协程来完成。

使用线程的好处就是不会出现界面卡死的情况，如果有一次非常大量的运算，没用线程就会出现假死的情况。

下面通过一个简单的例子来说明使用协程的好处：

void OnGUI()

{

GUI.Label(new Rect(0, 0, 200, 50), "测试1：" + result);

if (GUI.Button(new Rect(0, 100, 100, 50), "开启协程"))

{

StartCoroutine(GetResult());

}

GUI.Label(new Rect(200, 0, 200, 50), "测试2：" + result1);

if (GUI.Button(new Rect(200, 100, 100, 50), "无协程测试"))

{

GetResult1();

}

}

上面的代码表示在GUI中定义2个label和按钮，一个按钮启动协程计算，另一个直接计算结果。由于2个方法都是计算同样的结果，计算量比较大，所以直接计算出现了暂时的卡死情况。

float result;

IEnumerator GetResult()

{

for (int i = 0; i 1000; i++)

{

for (int j = 0; j 100000; j++)

{

result += (i + j);

}

if(i%100==0)

yield return 1;

}

}

这个方法是协程的写法，在C#中协程要定义为IEnumerator 这个类型，javascript中不需要。

yield return 1;这句话表示返回1帧的结果。在i为100的整数时，就返回一次结果，这样可以避免大量的计算卡死。

float result1;

void GetResult1()

{

for (int i = 0; i 1000; i++)

{

for (int j = 0; j 100000; j++)

{

result1 += (i + j);

}

}

}

这个方法就是直接计算结果，由于运算量比较大，所以界面会卡死，这样就可以体现出用协程的好处了。

使用IEnumerator 这个类型时，必须用yield return来返回结果，参数为数字时表示为帧数。

如yield return 1 表示每一帧返回一次结果。

可以帮我翻译一下这段英文吗(关于协程的描述)

该executation的coroutine可以在任何时候暂停使用产量发言。产量返回值指定当coroutine复会。 Coroutines良好行为时，模拟多个帧。 Coroutines几乎没有任何的性能开销。 StartCoroutine功能总是立即返回，但是，您可以产生的结果。这将等到couroutine已完成执行。

当使用JavaScript ，没有必要使用StartCoroutine ，编译器会帮您进行此动作。写作时C ＃代码，你必须拨打StartCoroutine

/ /在这个例子中，我们显示了如何调用一个coroutine ，并继续执行

/ /函数并行。

/ / -在0秒，打印“从0.0 ”

/ / -在0秒，打印“在WaitAndPrint油剂0.0 ”

/ / - 2秒钟后，打印“ WaitAndPrint 2.0 ”

打印（ “启动” + Time.time ） ;

/ /启动功能WaitAndPrint作为coroutine 。并等待，直到它完成

WaitAndPrint （ 2.0 ） ;

打印（ “在WaitAndPrint油剂” + Time.time ） ;

功能WaitAndPrint （ waitTime为： float ） （

/ /停止执行的waitTime秒

产量WaitForSeconds （ waitTime ） ;

打印（ “ WaitAndPrint ” + Time.time ） ;

）

功能StartCoroutine （ methodName ：字符串，值：对象=无效） ： Coroutine

描述

启动一个coroutine名为methodName 。

在大多数情况下要使用上述StartCoroutine变化。然而StartCoroutine方法使用一个字符串名称，您就可以使用StopCoroutine具体方法的名称。缺点是，字符串版本具有更高的运行时开销开始coroutine ，您可以通过唯一的一个参数

fiber javascript 可以做什么

1, 用 fiber 还是等语法层面的改进，我认为是见仁见智。我不认为让开发者关心一个调用是同步还是异步是一件好事情。

我在微博上面说过，异步是会向上传染的，语言级的协程无法根本解决异步问题。在一个层级较深的项目里面，一旦底层中有一个模块需要同步改异步或者相反(比如需要增加一次数据库操作)，向上的每一个层级都需要在语法上进行修改，这一点是灾难的。我不认为 js 能最终解决这个问题，最后必须回归堆栈级协程。

2, 从纯 js 性能来说，fiber 比 callback 要高出非常多。fibjs 的模块之间是最简单的函数调用关系，而 callback 则需要往返两次才能完成一次调用，期间还要结果组包，错误处理，保存工作状态等等耗时操作。同时 nodejs 的事件队列也是一个性能堪忧的东西。越复杂的应用，这些影响越大。

数据库操作，没有做详细对比测试。封装 leveldb 的时候简单测试了一下，fibjs 9w/s，nodejs 3w/s。http + mongodb 有网友测试结果在这里：，基本也是将近 3 倍。并且这些测试里面，fibjs 的瓶颈根本不在 fibjs 而 nodejs 则是已经跑满了。

javascript中异步操作的异常怎么处理

一、JavaScript异步编程的两个核心难点

异步I/O、事件驱动使得单线程的JavaScript得以在不阻塞UI的情况下执行网络、文件访问功能，且使之在后端实现了较高的性能。然而异步风格也引来了一些麻烦，其中比较核心的问题是：

1、函数嵌套过深

JavaScript的异步调用基于回调函数，当多个异步事务多级依赖时，回调函数会形成多级的嵌套，代码变成

金字塔型结构。这不仅使得代码变难看难懂，更使得调试、重构的过程充满风险。

2、异常处理

回调嵌套不仅仅是使代码变得杂乱，也使得错误处理更复杂。这里主要讲讲异常处理。

二、异常处理

像很多时髦的语言一样，JavaScript 也允许抛出异常，随后再用一个try/catch

语句块捕获。如果抛出的异常未被捕获，大多数JavaScript环境都会提供一个有用的堆栈轨迹。举个例子，下面这段代码由于'{'为无效JSON

对象而抛出异常。

?

12345678

function JSONToObject(jsonStr) { return JSON.parse(jsonStr);}var obj = JSONToObject('{');//SyntaxError: Unexpected end of input//at Object.parse (native)//at JSONToObject (/AsyncJS/stackTrace.js:2:15)//at Object.anonymous (/AsyncJS/stackTrace.js:4:11)

堆栈轨迹不仅告诉我们哪里抛出了错误，而且说明了最初出错的地方：第4 行代码。遗憾的是，自顶向下地跟踪异步错误起源并不都这么直截了当。

异步编程中可能抛出错误的情况有两种：回调函数错误、异步函数错误。

1、回调函数错误

如果从异步回调中抛出错误，会发生什么事？让我们先来做个测试。

?

1234567

setTimeout(function A() { setTimeout(function B() { setTimeout(function C() { throw new Error('Something terrible has happened!'); }, 0); }, 0);}, 0);

上述应用的结果是一条极其简短的堆栈轨迹。

?

12

Error: Something terrible has happened!at Timer.C (/AsyncJS/nestedErrors.js:4:13)

等等，A 和B 发生了什么事？为什么它们没有出现在堆栈轨迹中？这是因为运行C 的时候，异步函数的上下文已经不存在了，A 和B 并不在内存堆栈里。这3

个函数都是从事件队列直接运行的。基于同样的理由，利用try/catch

语句块并不能捕获从异步回调中抛出的错误。另外回调函数中的return也失去了意义。

?

1234567

try { setTimeout(function() { throw new Error('Catch me if you can!'); }, 0);} catch (e) {console.error(e);}

看到这里的问题了吗？这里的try/catch 语句块只捕获setTimeout函数自身内部发生的那些错误。因为setTimeout

异步地运行其回调，所以即使延时设置为0，回调抛出的错误也会直接流向应用程序。

总的来说，取用异步回调的函数即使包装上try/catch 语句块，也只是无用之举。（特例是，该异步函数确实是在同步地做某些事且容易出错。例如，Node

的fs.watch(file,callback)就是这样一个函数，它在目标文件不存在时会抛出一个错误。）正因为此，Node.js

中的回调几乎总是接受一个错误作为其首个参数，这样就允许回调自己来决定如何处理这个错误。

2、异步函数错误

由于异步函数是立刻返回的，异步事务中发生的错误是无法通过try-catch来捕捉的，只能采用由调用方提供错误处理回调的方案来解决。

例如Node中常见的function (err, ...)

{...}回调函数，就是Node中处理错误的约定：即将错误作为回调函数的第一个实参返回。再比如HTML5中FileReader对象的onerror函数，会被用于处理异步读取文件过程中的错误。

举个例子，下面这个Node 应用尝试异步地读取一个文件，还负责记录下任何错误（如“文件不存在”）。

?

1234567

var fs = require('fs'); fs.readFile('fhgwgdz.txt', function(err, data) { if (err) { return console.error(err); }; console.log(data.toString('utf8'));});

客户端JavaScript 库的一致性要稍微差些，不过最常见的模式是，针对成败这两种情形各规定一个单独的回调。jQuery 的Ajax

方法就遵循了这个模式。

?

1234

$.get('/data', { success: successHandler, failure: failureHandler});

不管API 形态像什么，始终要记住的是，只能在回调内部处理源于回调的异步错误。

三、未捕获异常的处理

如果是从回调中抛出异常的，则由那个调用了回调的人负责捕获该异常。但如果异常从未被捕获，又会怎么样？这时，不同的JavaScript环境有着不同的游戏规则……

1. 在浏览器环境中

现代浏览器会在开发人员控制台显示那些未捕获的异常，接着返回事件队列。要想修改这种行为，可以给window.onerror

附加一个处理器。如果windows.onerror 处理器返回true，则能阻止浏览器的默认错误处理行为。

?

123

window.onerror = function(err) { return true; //彻底忽略所有错误};

在成品应用中， 会考虑某种JavaScript 错误处理服务， 譬如Errorception。Errorception

提供了一个现成的windows.onerror 处理器，它向应用服务器报告所有未捕获的异常，接着应用服务器发送消息通知我们。

2. 在Node.js 环境中

在Node 环境中，window.onerror 的类似物就是process 对象的uncaughtException 事件。正常情况下，Node

应用会因未捕获的异常而立即退出。但只要至少还有一个uncaughtException 事件处理

器，Node 应用就会直接返回事件队列。

?

123

process.on('uncaughtException', function(err) { console.error(err); //避免了关停的命运！});

但是，自Node 0.8.4 起，uncaughtException 事件就被废弃了。据其文档所言，对异常处理而言，uncaughtException

是一种非常粗暴的机制，请勿使用uncaughtException，而应使用Domain 对象。

Domain 对象又是什么？你可能会这样问。Domain 对象是事件化对象，它将throw 转化为'error'事件。下面是一个例子。

?

123456789

var myDomain = require('domain').create();myDomain.run(function() { setTimeout(function() { throw new Error('Listen to me!') }, 50);});myDomain.on('error', function(err) { console.log('Error ignored!');});

源于延时事件的throw 只是简单地触发了Domain 对象的错误处理器。

Error ignored!

很奇妙，是不是？Domain 对象让throw

语句生动了很多。不管在浏览器端还是服务器端，全局的异常处理器都应被视作最后一根救命稻草。请仅在调试时才使用它。

四、几种解决方案

下面对几种解决方案的讨论主要集中于上面提到的两个核心问题上，当然也会考虑其他方面的因素来评判其优缺点。

1、Async.js

首先是Node中非常著名的Async.js，这个库能够在Node中展露头角，恐怕也得归功于Node统一的错误处理约定。

而在前端，一开始并没有形成这么统一的约定，因此使用Async.js的话可能需要对现有的库进行封装。

Async.js的其实就是给回调函数的几种常见使用模式加了一层包装。比如我们需要三个前后依赖的异步操作，采用纯回调函数写法如下：

?

12345678910111213141516

asyncOpA(a, b, (err, result) = { if (err) { handleErrorA(err); } asyncOpB(c, result, (err, result) = { if (err) { handleErrorB(err); } asyncOpB(d, result, (err, result) = { if (err) { handlerErrorC(err); } finalOp(result); }); });});

如果我们采用async库来做：

?

12345678910111213141516171819202122

async.waterfall([ (cb) = { asyncOpA(a, b, (err, result) = { cb(err, c, result); }); }, (c, lastResult, cb) = { asyncOpB(c, lastResult, (err, result) = { cb(err, d, result); }) }, (d, lastResult, cb) = { asyncOpC(d, lastResult, (err, result) = { cb(err, result); }); }], (err, finalResult) = { if (err) { handlerError(err); } finalOp(finalResult);});

可以看到，回调函数由原来的横向发展转变为纵向发展，同时错误被统一传递到最后的处理函数中。

其原理是，将函数数组中的后一个函数包装后作为前一个函数的末参数cb传入，同时要求：

每一个函数都应当执行其cb参数;cb的第一个参数用来传递错误。我们可以自己写一个async.waterfall的实现：

?

12345678910111213141516171819202122

let async = { waterfall: (methods, finalCb = _emptyFunction) = { if (!_isArray(methods)) { return finalCb(new Error('First argument to waterfall must be an array of functions')); } if (!methods.length) { return finalCb(); } function wrap(n) { if (n === methods.length) { return finalCb; } return function (err, ...args) { if (err) { return finalCb(err); } methods[n](...args, wrap(n + 1)); } } wrap(0)(false); }};

Async.js还有series/parallel/whilst等多种流程控制方法，来实现常见的异步协作。

Async.js的问题：

在外在上依然没有摆脱回调函数，只是将其从横向发展变为纵向，还是需要程序员熟练异步回调风格。

错误处理上仍然没有利用上try-catch和throw，依赖于“回调函数的第一个参数用来传递错误”这样的一个约定。

2、Promise方案

ES6的Promise来源于Promise/A+。使用Promise来进行异步流程控制，有几个需要注意的问题，

把前面提到的功能用Promise来实现，需要先包装异步函数，使之能返回一个Promise：

?

12345678910

function toPromiseStyle(fn) { return (...args) = { return new Promise((resolve, reject) = { fn(...args, (err, result) = { if (err) reject(err); resolve(result); }) }); };}

这个函数可以把符合下述规则的异步函数转换为返回Promise的函数：

回调函数的第一个参数用于传递错误，第二个参数用于传递正常的结果。接着就可以进行操作了：

?

123456789101112131415

let [opA, opB, opC] = [asyncOpA, asyncOpB, asyncOpC].map((fn) = toPromiseStyle(fn)); opA(a, b) .then((res) = { return opB(c, res); }) .then((res) = { return opC(d, res); }) .then((res) = { return finalOp(res); }) .catch((err) = { handleError(err); });

通过Promise，原来明显的异步回调函数风格显得更像同步编程风格，我们只需要使用then方法将结果传递下去即可，同时return也有了相应的意义：

在每一个then的onFullfilled函数（以及onRejected）里的return，都会为下一个then的onFullfilled函数（以及onRejected）的参数设定好值。

如此一来，return、try-catch/throw都可以使用了，但catch是以方法的形式出现，还是不尽如人意。

3、Generator方案

ES6引入的Generator可以理解为可在运行中转移控制权给其他代码，并在需要的时候返回继续执行的函数。利用Generator可以实现协程的功能。

将Generator与Promise结合，可以进一步将异步代码转化为同步风格：

?

1234567891011

function* getResult() { let res, a, b, c, d; try { res = yield opA(a, b); res = yield opB(c, res); res = yield opC(d); return res; } catch (err) { return handleError(err); }}

然而我们还需要一个可以自动运行Generator的函数：

?

123456789101112131415161718192021222324252627282930

function spawn(genF, ...args) { return new Promise((resolve, reject) = { let gen = genF(...args); function next(fn) { try { let r = fn(); if (r.done) { resolve(r.value); } Promise.resolve(r.value) .then((v) = { next(() = { return gen.next(v); }); }).catch((err) = { next(() = { return gen.throw(err); }) }); } catch (err) { reject(err); } } next(() = { return gen.next(undefined); }); });}

用这个函数来调用Generator即可：

?

1234567

spawn(getResult) .then((res) = { finalOp(res); }) .catch((err) = { handleFinalOpError(err); });

可见try-catch和return实际上已经以其原本面貌回到了代码中，在代码形式上也已经看不到异步风格的痕迹。

类似的功能有co/task.js等库实现。

4、ES7的async/await

ES7中将会引入async function和await关键字，利用这个功能，我们可以轻松写出同步风格的代码，

同时依然可以利用原有的异步I/O机制。

采用async function，我们可以将之前的代码写成这样：

?

12345678910111213

async function getResult() { let res, a, b, c, d; try { res = await opA(a, b); res = await opB(c, res); res = await opC(d); return res; } catch (err) { return handleError(err); }} getResult();

和Generator Promise方案看起来没有太大区别，只是关键字换了换。

实际上async

function就是对Generator方案的一个官方认可，将之作为语言内置功能。

async function的缺点：

await只能在async function内部使用，因此一旦你写了几个async function，或者使用了依赖于async

function的库，那你很可能会需要更多的async function。

目前处于提案阶段的async

function还没有得到任何浏览器或Node.JS/io.js的支持。Babel转码器也需要打开实验选项，并且对于不支持Generator的浏览器来说，还需要引进一层厚厚的regenerator

runtime，想在前端生产环境得到应用还需要时间。

以上就是本文的全部内容，希望对大家的学习有所帮助。