找出微服务性能方面常见的反模式

在上一篇文章中,我们介绍了如何诊断Java代码中常见的数据库性能热点问题。在本文中,我们将对在分布式面向“微”服务架构(SOA)中造成性能与可伸缩性问题的各种模式进行针对性的讨论,例如在一个低延迟连接中传输大量数据,或是由于糟糕的服务接口设计造成了过多的服务调用,以及线程与连接池耗尽等等。

近期我帮助一个应用进行了分析,就让我们以此为例。该公司迫切地需要将他们的旧式一体性应用转变为面向服务的架构,以满足这个非常受欢迎的 网站不断发展的需求。这个应用的标志性功能在于它的搜索特性。搜索逻辑原先是在前端的web展示代码中实现的,而现在则转移至新的后端搜索REST API中。我们对它的架构进行了审查,执行了多种不同的搜索查询,其结果令人相当吃惊。每个搜索关键字会产生对后端搜索REST API不同次数的调用。看起来其搜索结果中的每一项都会对内部的搜索REST API进行一次调用,这是一个典型的N+1查询问题模式。下图展示了某次搜索产生的Dynatrace事务流的截图,它得到了33个搜索结果。从中可以很 容易地发现几个糟糕的服务访问模型,我将在本文稍后部分对其细节进行分析。我通常总是会对关键的架构指标进行分析,从这个例子中我们可以看到,该应用恐怕 无法具备其设想中的伸缩能力与性能。

通过对一些关键的输入与输出的服务调用进行检查,可以使我们更容易发现服务调用的问题模式。而通过对这些数据进行检查,也使我们能够更方便地进行架构与代码的审查。

我明白,这种错误不会发生在你身上!☺

我曾在全球范围内的用户组与会议中多次展示了这个搜索功能的用例,所得到的回应通常都是“这种事情不会发生在我们身上,我们知道如何正确地开发服 务”。但请继续读下去,你会发生类似的错误会经常发生在实际的生产环境代码中!没有人会有意这么做,但它确实发生了。按我的观察来看,发生这种问题的原因 有三个:

1:未察觉或理解整体情况

服务开发团队通常只关注于他们负责开发的服务,他们投入了大量的精力以实现服务的可伸缩性与性能,但也因此忽略了整体情况。这个服务会以怎样的方式使用?我们是否为满足服务调用者的要求提供了正确的接口方法?

在以上示例中,搜索REST API团队提供了一个服务方法GetProductDetails(int productId)。但他们真正应当提供的方法是GetAllProductDetails(string searchQuery)或GetAllProductDetails(int[] productIds)。我建议每个服务团队经常性地与你的客户与调用者进行交谈,不仅要明白他们自认为需要怎样的服务,同时也要确保在你的实现中包含对 服务使用情况的监控能力,在生产环境中了解每个服务的使用频率与使用者!

2:不了解框架的内部实现

大多数团队都不会自行开发自有的框架,而是依赖于现有的各种流行框架,例如MVC和REST。这种方式是正确的,我们不应当每次创建新的应用时都重 复发明轮子。但有一种错误是经常发生的:在启动一个新的项目时,我们通常会基于某个从GitHub这种公共代码库中下载的示例开发一个原型,该原型经过数 次演化就会转变为一个完整的应用,但团队会因此忽略了对此进行必要的回顾的过程,以评估该框架是否是最适合这项任务的选择,以及是否对该框架进行了最适当 的调整优化。我的建议是花一些时间去了解你所选择的框架的内部机制,以及如何进行最佳的配置与优化,以实现最好的吞吐量与性能。否则的话,你就要准备好面 对上文所描述的情形。这种情形我每天都能观察到!

3:迁移或是重新设计架构

当你准备将现有的一体性应用进行分解时,不要单纯地认为你可以分解出提供某种功能的类,随后将其包装为一个服务。这种方式会造成原先的本地线程内与进程内调用变成跨服务/服务器/网络/云平台的调用,而这一点往往会被忽略,因为对这些服务的调用就像调用本地方法一样简单。

当你从一体性架构迁移至微服务时,请确保你首先理解服务的API到底需要提供什么功能。在多数情况下,这意味着你需要重新设计架构,并对接口进行重新定义,而不是将代码从原先的一体性项目中拷贝至多个服务项目中。

可用的诊断工具与选项

正如以上示例所示,我总是会检查一些关键的架构指标,例如服务器之间的调用频率与调用次数、所传输的数据量,并了解服务之间的相互通信是怎样的。通 常来说,你可以从用于开发应用的服务框架中获取这些指标,例如Spring、Netflix等等。大多数框架都会提供诊断与监控相关的特性,你也可以自行 选择代码性能诊断工具,或选择某种可用的应用性能监控(APM)工具,可使用完全免费的版本,或是高级/免费试用的版本。我所选择的工具是 Dynatrace Application Monitoring与UEM,只需遵守Dynatrace个人许可,开发者、架构师与测试人员就可以免费试用。这种工具的一个关键场景在于它能够展示整个服务基础设施中的数据以及服务的交互方式,而性能诊断工具只能够对一个单一的JVM进行分析,因此其功能对于我们的要求来说过于受限。

诊断糟糕的服务访问模式

现在,让我们看看这个我希望各位留心提防的服务访问模型清单。如果你希望以面向服务架构开发一个高伸缩、高性能的应用,请确保你检查应用中是否存在这些模式的痕迹。我们首先列举出这个清单,随后展示一些出现了这些模式的示例应用,以找出并克服其中的性能问题:

  • 过多的服务调用:在单一的端到端用例中出现了过多的服务调用。那么多少次调用算是太多呢?这当然取决于你的应用和需求,以及你如何划分你的服务。但从经验来看:如果达到5次服务调用,就说明你应当开始调查其原因了。
  • N+1服务调用模式:在某个端到端的用例中对相同的服务进行多次调用。这个问题的出现表示你可能需要重新定义你的服务终结点,并提供一个更具特定性的服务。简而言之,就是“给我这个查询结果中所有产品的细节”,而不是“给我产品X,再给我产品Y的细节”。
  • 服务的网络传输信息过大:带宽确实很便宜,但这一点仅限于你的终结点部署地点非常接近的情况下。一旦你将服务迁移至云平台,你就要考虑 到高延迟、不同的带宽限制、以及云提供商对于你的云实例所发送及接收的流量所产生的额外成本。如果我发现内部的服务调用所传输的数据量大于返回给终端用户 的数据量,我就会开始研究如何对传输数据进行优化。
  • 连接池与线程池的大小:服务都是通过连接进行通信的,因此我们需要对负责发送与接收的连接池与线程池进行适当的调整与观察。一旦你理解了服务之间通过哪些通道进行通信,你就可以基于对负载的预测进行适当的调整。
  • 过多地使用异步线程:要实现一个事件驱动的服务调用模式,使它支持发起异步调用,并在完成后收到通过,而这一点并不容易做到。需要留意的是,有些框架会产生“虚假的”异步行为,它会产生及阻塞后台线程,直至每个服务调用的结果都返回为止。
  • 对架构的违反:你的服务是否按预期的方式与其他服务进行交互?你的架构中是否出现了某些预计之外的访问反模式(打个比方,你是否直接访问了某个后台数据存储系统,而没有经过数据访问服务API)?
  • 缺少缓存:将实际的工作转移至服务是一种正确的做法,但如果这会导致该功能实际效率的下降,你或许会面临资源方面的问题。一个常见的例子是向服务器发起重复的访问,而不是在多次服务调用之间对数据进行缓存,以避免对数据库的不断请求。

好了,我将信守承诺,让我们实际地看看解决这些问题的技术吧:

示例1:过多的服务调用与N+1查询模式

该示例来自于一个著名的求职网站。每当终端用户执行一次搜索请求时,前端的服务就会查询能够满足用户所输入的搜索关键字的职位信息。对返回 结果中的每个职位信息,该服务都会向一个外部“搜索”REST服务发起调用。这个过程可以很容易地进行优化,只需提供一个粗粒度的搜索REST调用,让它 接受一个职位信息的列表,就能够极大地减少REST调用的次数:

对前端服务的一次职位信息搜索请求造成了对某个外部服务共38次REST调用,以获取每个职位的详细信息。可以通过提供某种更恰当的REST接口对其进行优化,让该接口返回一系列职位信息的结果!

仅仅从调用的次数来看,还不能肯定地说这究竟是一种糟糕的设计,还是说在前端与后端之间的REST接口的一种低效率的使用方式。为了了解实 际情况,你需要观察实际执行的REST查询,将这些查询以终结点的URL和查询字符串进行组织。通过这种策略,就可以发现真正的问题所在,即N+1查询问 题,每个重复的REST调用重用了完全相同的查询字符串:

通过对终结点与查询字符串进行观察,可找出对某个REST终结点的低效率调用方式。如果你的系统中出现了这些模式,可以考虑提供更恰当的接口,以一个单一的服务调用处理这些查询。

在以上这个示例中,每次进行职位查询时,对于不同的职位信息都需要重复地多次调用相同的服务。如果你的服务也遇到了相似的情况,那么合理的 方式是提供一种能够更好地支持端到端用例的REST接口。另一种可能是你的服务已经提供了这种接口,但前端开发者(或是服务的调用者)并未意识到这种接口 的存在。通过进行这种方式的使用情况分析,你实际上已经对调用者进行了一次培训,让他们了解如何更好地利用你的服务!

提示:在Dynatrace中,你可以在Web Requests Dashlet中显示某个端到端事务所产生的所有调用。请确保你在上下文菜单中对Dashlet进行了正确的设置,选择“Show -> All”以及“Group By -> URL + Query”模式。

示例2:过度使用异步线程

同样是在这个搜索职位的示例中,访问了/getResult这个URL的所有调用在执行时会为每个服务调用生成一个新的后台线程,因此,在 HTTP主线程中共生成了35个线程,以并行执行这些REST调用。这样一来,HTTP工作线程将处于阻塞状态,直到所有的后台线程全部执行完毕为止:

分析REST调用的执行过程中共牵涉到多少线程。如果你的系统中出现了N+1服务调用模式,那么前端每次发起的请求都会消耗N个额外的线程!

很显然,这35个线程的产生是由于N+1服务访问模式所引起的。如果该模式得到解决,那么在每个服务调用时占有一个新的线程的问题也迎刃而解了。

示例3:线程的比率与线程池

通过分析传入的请求/事务与执行过程中所牵涉到的活跃线程总数之比,也可分析出示例2所描述的问题。你可以通过查看JVM中所产生的JMX Metrics访问这两种指标。你甚至还可以进一步扩展你的分析,将线程数量按照线程组进行分解。如果你的应用如以上示例所示,为这些线程进行了恰当的命 名,那么这种方式的价值将更为明显,同时这也是一种正确的开发模式。同时,你还应当观察CPU的占用情况,如果你的应用表现出性能的下降,却没有观察到 CPU占用的提高,那就表示你的线程或许在等待I/O或是其他一些操作的结果。

一种优秀的实践是将传入请求的数量与活跃线程总数及CPU占用率情况进行关联。如果这一比例是26比1,就表示你的应用为每个请求产生了大量的后台 线程。并且对线程数量的持续观察能够使你了解是否遇到了“瓶颈”。正如上文中的示例所示,工作线程的最大数量是1300,如果请求的数量超过这个值,那么 后续的请求就会因为线程不足而无法处理!

在整个管道中对服务的指标进行监控

上一篇文章中, 我们提到了数据库指标,以及如何将这些指标与你的持续集成(CI)构建过程进行整合。同样的方式也可以用于服务的指标。如果你已经实现了服务的自动化测 试,已经能够对搜索或某些消息通知功能进行自动化测试,那么你也应当以自动化方式监控每个单一的测试执行过程中的指标。但即使已经完成了CI,也应当继续 保持对软件的监控?其原因在于你所测试的软件将被部署至预发布环境,甚至可能是生产环境,在这些环境中对于那些指标的监控也同样重要。在我看来,最有价值 的部分在于你是否能够保持当服务部署至生产环境之后对类似的指标进行观察。此外,你还应当对于各种服务特性的使用情况进行监控,让你能够更好地了解调用者 实际使用了哪些新的服务/特性。当你获取了这些指标数据之后,就能够以此决定需要对哪些特性进行改进,以提高使用率。如果特性的使用情况不符合你的预期, 也可以移除这些特性。这将有助于你减少代码的体积和复杂度,并最终减少被业界称为“技术债”的东西。

我们将快速地介绍如何实现这一点,仍以我描述的示例为例,该产品的搜索特性会造成33次服务调用。首先分析的是早期版本的软件,当时整个应 用还属于一种“一体性”的应用。通过CI中的测试,我们可获取关于消息通知以及搜索特性的相关指标,包括代码如何与数据库进行调用、产生的服务调用次数有 多少、所传输的数据量有多大,以及在生产环境中有哪些特性得到了使用:

第17号构建的分析结构展示:消息通知与搜索功能在生产环境中性能表现不佳。消息通知的使用率非常低下,原因可能在于它的响应时间过长,让用户不愿意使用这一特性。搜索功能的使用率还比较出色,但本应表现得更好。

通过对这些指标进行分析,我们就能够理解代码运行的情况,因此我们可决定对性能进行优化,将一体性的搜索特性分解为面向服务的方式。经过数 次构建之后,我们完成了新的面向服务实现。但是,在经过了相同的测试之后,却出现了一些意料之外的指标数据,这使我们不得不推迟了新代码在生产环境中的发 布。从下图中可以看出,我们对于搜索功能所做的变更显然违反了各种架构规则(这些数字都来自于我在开篇第一段所介绍的示例):

第25号构建显然是一个很糟糕的构建,迁移后的微服务架构在服务调用模式上表现出非常糟糕的性能指标。请不要部署这个构建,而是修复其中的问题!

N+1查询问题模式也造成了大量的SQL查询,以及通过网络进行传输的数据。修复这一问题的方式是为新的后端搜索服务接口选择一种更清晰且 更高效的设计实现。它不会为每个搜索结果都调用一次后端服务,而是引入了一种“批量”式的服务,以返回搜索结果的全部细节。在完成了修复工作之后,我们终 于可以部署新的构建了。从持续集成服务器上来看,一切数据都表现良好。从部署后在生产环境中产生的使用数据来看,运行在多个服务容器中的搜索功能得到了更 好的性能,并表现出更好的使用率。不过,消息通知这一特性的使用率只得到了很少的提升。这或许意味着我们应当在今后的构建中移除这一特性,因为很显然它并 没有提供多少价值:

第26号构建已经具备了一个非常扎实的技术基础,在搜索功能的使用率上也得到了提升。但消息通知的使用率并没有多少提升,因此我们决定在第35号构建中移除这一特性。

在前一篇关于数据库的文章中,我们提出了一种通过Dynatrace在测试自动化与持续集成过程中以可视的方式展现架构指标的能力。通过将 其中的数据与下图进行比较,就可展现出我们的搜索服务在生产环境中产生的各种关键架构指标。举例来说,下图中的黄色、橙色与绿色部分可表示有多少个搜索请 求的执行所产生的内部REST调用数目在1至5之间(黄色)、或是5个以上(亮黄色)。除此之外,我们还比较了SQL调用执行的次数(橙色)以及每次搜索 平均产生的数据量(绿色)。这种可视化能力能够帮助我们找到服务的使用情况的变更(在Y轴上的总数),以及行为的变化(即某种颜色块所占部分变大或变 小)。

生产环境中的服务监控:理解代码部署后的使用情况以及内部行为

尽早掌握你的服务的运行情况

如果你还没有开始基于指标对架构进行审查,我建议你立即着手实践。请观察我所描述的各种模式,并告诉我们是否还有其他一些需要留意的模式。但这一过 程不应当仅限于在编写代码阶段进行人工观察,你应当以DevOps实践对监控工作进行自动化,并更好地决定部署哪些特性、对哪些服务进行改进、以及要放弃 哪些服务。

关于作者

Andreas Grabner(@grabnerandi)是一位研究性能问题的工程师,他在过去十五年间一直致力于这一领域方面的工作。Andreas的工作是帮助组织找出应用程序中的真正问题,并将从中获得的知识作为工程最佳实践分享给他人,使他们了解如何避免这些问题。

查看英文原文Locating Common Micro Service Performance Anti-Patterns

【ArchSummit深圳2016】48小时,百余位资深技术专 家,Twitter、LinkedIn、Cloudera、百度、腾讯、阿里、Uber、滴滴、美团等争奇斗艳,这就是这个夏天ArchSummit在深 圳掀起的技术狂潮。爱技术、爱分享,ArchSummit深圳2016我们等你!详情请点击
发表在 SOA, 未分类 | 发表评论

多任务处理对组织的经济效应

多任务处理对组织的经济效应

作者 Savita Pahuja ,译者 陆志伟 发布于 2016年4月27日 | 讨论

Aigle For All的创始人和合伙人 Bob Hartman是一名经过认证的 Scrum培训师和教练,最近写了一篇 Peter Drucker’s view is integral to the values of Scrum文章。在这篇文章中,他解释了多任务处理是如何影响组织经济的,并对 Peter Drucker的引用进行了阐述。

经济效益的关键在于专注(concentration)。如今,没有一个有效性原则像专注基本原则一样被不断地违反。

Bob重点强调了 Scrum的“专注”价值。他说:

当我们开始与客户合作时,在组织的任何层级很难看到任何形式的专注。多任务处理不仅猖獗,而且能够完成的很好被认为是一种令人钦佩的特性!很明显,大多数管理者和主管不了解多任务处理花费的巨大代价,和由于多任务处理的效应造成多少生产力的损失。

Bob在 Peter Drucker的引用中如是说到,其中单词“专注”可以等同于“不多任务处理。”因此 Peter切实说到,不多任务处理“是经济效益的关键。”换句话说,如果你想做一件事并产生经济效益,请专注这件事!它造成一种有趣的表述:如果你专注专 注,那么你会取得更好的结果。

通常人们会忽略多任务处理的最坏影响,但是在现实中,如下图 Bob提到的曲线图所示,这种惩罚非常严重。根据该曲线图,多任务处理中每增加一个项目,惩罚就会提高20%。

不动产投资者和企业所有人 Carol Deeb在她的文章 Bad Effects of Multitasking中指出,当员工不断地被不必要的干扰打断时,企业和经济会遭受多么大的影响!她提到,纽约时报引用了 Basex 2007年的研究,一个咨询公司研究员工如何使用电子设备协同执行任务,并得出如下结论:

Basex估计,由于工作绩效不足,企业每年损失6500亿美元,同时注意力分散使得企业创造力下降。如果员工失去对任务的专注,失去对寻找帮助企业实现财务目标的解决方案的专注,利润会受到影响。

基于流的计划与执行解决方案提供商 Realization发布了一份多任务对组织影响的报告,报告中揭露了组织的多任务处理问题,通常在大型公司没有人会注意到这个问题,导致每年全球经济由于生产力下降损失超过4500亿美元。

Bob建议我们应该向高层管理人员以美元的形式提交浪费的生产力,从而吸引他们的注意力,并鼓励他们避免多任务处理。

Realization的报告引用了基于流的项目管理作为解决方案来提高组织生产力,并专注攻击生产力损失和组织多任务处理的最大原因。该方法包括以下三个步骤:

  1. 减少 20%到 50%打开项目或者工作流的数量。
  2. 建立明确的任务优先级规则。
  3. 没有充分准备之前不要开始项目。

查看英文原文Economic Effects of Multitasking on an Organisation


感谢张龙对本文的审校。

发表在 未分类 | 发表评论

钢价报复性反弹 钢市重回3000元时代

能与大葱价格媲美的,现在是螺纹钢。

4月21日,中国最大民营钢企沙钢集团将螺纹钢、高线、盘螺出厂价上调550元/吨,涨幅高达21%。该三类产品涨后价格分别为每吨3060元、3130元、3140元。这是建筑钢材一年多来首次站上3000元大关。

江苏永钢和中天钢铁亦同步调价550元/吨。福建三宝、济源钢铁和方大特钢等企业的螺纹钢出厂指导价则上调220-300元/吨。上涨幅度相对较小的莱钢、柳钢、水钢和马钢也上调了100-120元/吨。

兰格钢铁云商平台监测数据显示,4月21日,北京市场三级螺纹钢的价格是2980元,较年初上涨66.5%;与去年12月10日最低价格1600元相比,涨幅为86.3%。郑州、西安、成都、杭州等地的三级螺纹钢价格均超过3000元。

此次调价在一定程度上是钢厂与钢贸商互相逐利的结果。

西 本新干线首席研究员邱跃成告诉界面新闻记者,钢厂出厂价一般为十天一调,沙钢的螺纹钢在调价前的价格为2510元/吨,代理商拿货价格为2410元/吨。 4月20日,螺纹钢市场价格已卖到2900多元/吨,代理商每吨利润达到近500元,“钢厂想获得更多利润,就有动力把价格追上来”。

期货与现货市场的互相拉涨效应亦颇为明显。黑色系期货市场已连续多日表现强势。4月21日,螺纹钢期货主力合约涨幅高达7.5%,至2787元/吨。这已是期螺连续第四天上涨,该品种本周已上涨近20%,今年累计涨超50%。

当天,螺纹钢RB1610合约成交量的名义本金高达5500亿元,期螺成交金额则高达6056亿元,超过沪深两市总成交额5421亿元。

“这已经不能再用供需错配来解释了。”邱跃成对界面新闻记者称,近期股市、债市双双震荡下跌,有相当规模的资金开始涌入大宗商品期货市场。由于大宗商品价格尚处于低谷,加上有“供给侧改革”等政策利好预期,适合逢低炒高。

尽管“金三银四”已近尾声,但由于库存较低,且需求复苏情况超预期,大量资金尚在不断涌入,市场情绪持续高昂,钢市回暖趋势还将继续维持一段时间。

自去年12月中旬以来,这波行情已持续四个多月,不断超出业内预期。业内多将这波堪称“疯狂”的行情解释为“持续了五年的超跌后的报复性反弹”。

钢厂和钢贸商在久经亏损后,希望助推市场趋涨情绪,但这并不是下游用户希望看到的。邱跃成称,“涨价后的出货量已明显比前三天弱很多,大约降了一半左右。”终端用户对眼下高价位持谨慎和观望态度,后续价格走势将是上下游博弈的过程。

兰格钢铁信息研究中心主任王国清则认为,市场向来“买涨不买跌”,在这波接连突破预期的涨情下,多数下游用户“已经开始慌张”。加上近两月是需求旺季,将支撑钢价在3000元关口坚持到5月,随着高温多雨的6月到来,建筑钢材迎来淡季,钢价或将开始掉头向下。

发表在 未分类 | 发表评论

中国在“裸泳” 空前繁荣的3000亿美元市场将瓦解

“最后一块泡沫”最终破灭,随着中国企业债券泡沫迅速破灭,似乎投资者也受到波及,正如一位分析师警告“随着整个经济企业信用风险和银行风险的出 现,信用风险成本不断增加。”彭博社报道称,4月份中国的地方债发行者取消了619亿人民币(96亿美金)的债券销售,标准普尔自2003年来以前所未有 的步调降低中国企业的信用评级。简单来讲,中国空前繁荣的3000亿美金企业债券市场即将瓦解。







中国总融资第一季度增长超过1000亿美金

彭博社报道,中国面临两难局面。

一方面,允许陷入困境的公司违约迫使基金经理注重信用风险,加快政府运作遏制产能过剩危险。虽然,是投资者的恐慌情绪导致信贷紧缩,近而影响了未来五年保持至少6.5 %的经济增长。

正如我们以前指出,3月份的经济数据揭示发展对债务日益依赖。中国的总融资——包含企业债券的广泛信用举措-第一季度增长超过1000亿美金……

然而即使这样并不足以挽救七家今年违背债券义务的公司。其中部分国有的三家公司,不久前被视为债券持有人的隐性担保机构。

在中国18.8万亿人民币企业债券市场,投资者反应迅速(数据不包括存单)。额外收益的投资者,对持有高于政府票据收益的七年陆内最高评级的企业债券需求自九年以来一月份最低值28个基点上涨至周一91基点。







投资者反应迅速

据报道,至少64家中国公司已经推迟或取消本月原定计划的票据销售,比上年同期多六倍。

克里斯托弗·李,标准普尔香港分公司大中华区首席评级主任表示:“随着越来越多的发行人违约,贷款人和投资者将重新评估他们的投资组合和贷款,那将导致收益率上扬”。”如果陆内市场有任何的差池,将会对海外市场产生溢出效应。”

西班牙对外银行香港分部亚洲首席经济分析师夏乐表示,上涨的违约实际有益于中国债券市场的发展。

夏乐表示:“这表明政府带走了隐性担保,现在风险意识上升,所以我们会看到哪些发行人是在裸泳。”

虽然中国的国债收益率仍远低于历史平均水平,借贷成本持续的增加可能威胁经济,使其比以往任何时候都更加依赖廉价信贷。数字表明今后将出现更多的困难:

至少自1992年以来,所列企业担负它们债务的能力已降至历史最低水平,自全球金融危机以来,上海综合指数公司分析师们都在最大程度的削减利润预测。

正如信达澳银深圳分部的基金经理邱鑫所说……

“信用风险的爆发只发生在中国的早期。”

我们把它留给夏乐作为访问结束部分,西班牙对外银行亚洲首席经济分析师夏乐表示“股市崩溃只是反映了对中国经济的担忧,而债券市场的崩溃意味着忧虑已成为现实,像如今企业拖欠债务,中国的信贷崩溃将很可能导致新兴市场资产的大幅度抛售。”

“全球投资者正在寻找中国崩溃的迹象……这个游戏不能永远持续下去”。

发表在 未分类 | 发表评论

吴晓波:EMBA死了

阿泰是我二十多年的朋友,开着一家市值十多亿的公司,这些年,只托我办过一件事,就是读EMBA。







位于杭州西湖鹆鹄湾附近的湖畔大学

他十七岁就开始跑单帮,连高中都没有毕业,而根据有关规定,每个EMBA班只有5%的名额留给他这样的学生。我为他当推荐人,先后报名了三家商学院,最后才被录取。阿泰读书的目的有两个,一是吸吸氧,二是交朋友。

从明年开始,像阿泰这样的企业家基本上就与EMBA绝缘了。

本 月,教育部下发文件,要求从2017年起,EMBA统一纳入全国硕士研究生考试招生,“由教育部划定统一的分数线并向社会公布,培养院校按照国家统一招生 政策自主录取。”据说,这个政策的出台,“主要是针对部分院校办学定位不准、办学思想不够端正、办学行为有失规范等乱象。”

也是在这个月,还有一则与企业家教育有关的新闻。马云老师在杭州拿下300亩地,要建湖畔大学的实体校园,阿里巴巴集团参谋长、曾是长江商学院教授的曾鸣出任教务长。

与EMBA新制度截然不同的是,湖畔大学的入学制度是举荐制,报名者必须有三位推荐人,至少一位是湖畔大学指定推荐人,指定推荐人则包括校董、保荐人和往期校友。保荐人由校董提名并投票产生。

好吧,我们先在这里做一个投票调查:如果你是一位企业经营者,同样的学费,你是愿意参加全国统一考试读EMBA,还是去读湖畔大学。

此刻,我在写这篇专栏的时候,当然不知道大家投票的结果,但是我几乎可以肯定地认为,选择前者的比例,应该不会超过三成。

这并不是说,湖畔大学一定是一所多么优秀的大学——它现在还仅仅是一个构想中的概念,但是,它符合企业家教育的基本原理,而全国统考模式,很可能让繁荣了十多年的EMBA陷入一个空前的尴尬。







湖畔大学第二届开学典礼:学习赛艇

在所有的专业能力上,有几种职业人是考试无法考出来的,甚至不是能够用学院的模式培养出来,比如作家,比如企业家,他们基本上都属于天生地养的自由物种,他们的工作是对不确定性提出挑战,而且不能以前人使用过的方式。

阿泰,或者其他读过大学的企业家们,到商学院读书,绝大多数都不是为了要一张文凭——那东西真的只值一张A4纸的价格,“百战归来再读书”,学的是各取所需。因为,企业家从来不是标准件,所以,真的无法用标准化的方式去“考试”他、塑造他。

过往这些年,EMBA教育遭到的最大的病垢有两个,一是它成为了官商勾结的温床,二是有些商学院的EMBA更像一个俱乐部而不是严谨的在职教育平台。

关 于前者,这是整肃吏政的内容,与EMBA教育没有必然的关联,况且中央已经关掉了官员上学的大门,关于后者,那是各家商学院自己的事情,EMBA招生在地 域和行业上没有限制,企业家如何选择,全靠口碑和自由决定,一家以打高尔夫为主业的商学院,肯定有它“精妙”的算度,且会对这样的风格承担全部的后果,马 校长如果想让他的小学同桌入读湖畔大学,你何必拦着他?

在我看来,就整体而言,中国EMBA教育最大的问题,并不在上述两则,而是教育质量 的提升不足。当今中国的企业发展越来越具备自己的特征,在商业模式的创新、管理制度的变革、企业组织的迭代以及技术突破的路径选择等方面,都有很多可以切 磋和深入研讨的课题,EMBA实则是学院研究者与一线实践家共同参验的、最合适的课堂。







国外的EMBA课堂

但可惜的是,当今商学院绝大多数的教授们离企业实践实在太远了,他们还在拿哈佛商学院的案例上课,还在用五年前甚至十年前的PPT,或者拿几个网络笑话驱走课堂里的哈欠。过去几年,在几家知名度最高的商学院里,都发生过学员愤怒罢课的尴尬事件。

所以,中国的EMBA教育要提高质量,唯一可能的驱动者是商学院本身,教育部屈尊干预,不知能否对结果负责。

说实在的话,有关部门为什么要将EMBA纳入全国统一考试,我百思不得其解。

“官商勾结的温床”,这个事情显然不是全国统考能杜绝的,EMBA像一个社交俱乐部,好像也不是几张试卷能解决的,至于教学与实践脱节的问题,则更与考试无关。







每个人,都有一张属于自己的社交图

一个最要命的问题是,这个世界上真的有人能够弄出一张考卷,来评估全中国的企业家,哪几个能读EMBA而哪几个不够资格吗?

我真的很好奇,这个老师长得有多帅。

有关部门的这个决定,最可能导致的结果是,企业家群体对EMBA集体失去兴趣,转而投向于其他的教育形式。在这个意义上,倒也可能是一件好事,它将极大地推动民营企业家教育机构的活跃,譬如湖畔大学、黑马营、正和岛以及即将开张的新物种学院等等。

罗纳德·科斯把中国改革的成功归结为“人类行为的意外后果”,即改革的成果非常喜人,可是,它的实现路径无法用逻辑理性全面地解释。

教育部门对EMBA的新规定,也很可能产生具有喜剧意义的意外后果。

只是这样的过程,太幽默了。

发表在 未分类 | 发表评论

加息预期转变令美元、油价走势逆转

国金融市场走势周四急剧逆转,美元尾盘走高,原油价格则大幅回吐了早盘涨势,原因是美国联邦储备委员会(简称:美联储)加息时间可能早于预期的前景对全球投资者人气遭成影响。

美 国劳工部周四公布的上周首次申请失业救济人数降至四十年低点,之后欧洲央行(European Central Bank)官员的讲话为进一步降息打开了大门,这导致投资者对全球央行利率环境进行重新考量。此前一些分析师暗示,如果美联储一段时间内按兵不动,美元的 此轮长期涨势可能会结束。

华尔街日报美元指数周四收涨0.2%,至86.21。美元上涨使原油价格回吐了早些时候的部分涨幅,纽约商交所原油期货结算价报每桶43.18美元,盘中早些时候曾一度触及五个月来最高水平。此外,美国股市也告跌,道琼斯指数收跌0.6%,至17982.52点。

尽管投资者仍然认为美联储几乎不可能在4月27结束的下一次政策会议上收紧货币政策,但一些人认为,近期强劲的美国经济数据及油价的上涨可能会开始推高通胀。这可能会导致美联储暗示6月份加息的可能性上升。

由于投资者押注美联储的加息态度比其他国家更为激进,2015年美元累计上涨8.6%,但2016年至今,美元下跌了4.4%,原因是市场预计美联储将放慢加息速度。

不过,市场可能低估了美联储的加息步伐。波士顿联邦储备银行行长罗森格伦(Eric Rosengren)周一表示,他认为美联储下次加息时间将早于许多投资者的预期。

据芝加哥商业交易所集团(CME Group)的数据显示,投资者和交易员用来押注央行政策的联邦基金利率期货目前表明,美联储于今年年底前加息的可能性为65%,高于周一的54%。数据显示,6月份加息的可能性为21%。

周 四市场走势的突然急剧逆转反映出,一些投资者担心,相较于基本面因素来说,大宗商品价格和股市近期涨势更多地与趋势交易相关,因此,如果利率或其他预期发 生转变,大宗商品和股市就极易迅速下跌。投资者对于原油价格的担忧尤为严重。即便主要产油国此前未能达成限产协议,而且反应供应过剩在短期内何时得以缓解 的数据喜忧参半,油价在本周早些时候仍继续攀升。

Ira Iosebashvili

发表在 未分类 | 发表评论

微软云计算业务增长放缓

向云端按需计算领域转型的微软(Microsoft Co., MSFT)在最近一个财季显出些许颓势,其云计算业务收入增长放缓。

截至3月份的第三财季,微软智能云(Intelligent Cloud)业务收入增长3%,至61亿美元,按照固定汇率计算增幅为8%。智能云业务包括按需计算服务Azure以及常规的服务器软件产品。微软称,Azure的收入按照固定汇率计算增长了120%。

而在第二财季,微软智能云业务收入增长了5%,按照固定汇率计算增长了11%,Azure收入的增幅更是高达140%。

券商Pacific Crest Securities的分析师巴尼克尔(Brendan Barnicle)认为,微软云业务增长无疑放缓了。但他同时指出,Azure只占微软总收入的一小部分,而且属于相对较新的业务。

另外,微软第三财季利润也没有达到分析师的预期。当季调整后每股收益持平于上年同期的62美分,比接受汤森路透(Thomson Reuters)调查的分析师给出的预期低2美分。

微软首席财务长胡德(Amy Hood)将此归因于一项“补涨”税项调整,这一调整是因预期全年税率会升高。她在接受访问时说,如果剔除这一税项因素,当季每股收益接近66美分。

微软旗舰操作系统Windows的销售追随了个人电脑行业的下滑趋势,但包括Windows在内的更加个性化计算部门(More Personal Computing)更具弹性,该部门收入微幅增长0.9%,至94.6亿美元,营运利润增长57%。

微软最新版本Windows 10操作系统的普及比以往任何版本都更快。不过,电脑生产商的Windows收入按固定汇率计算下降了2%。微软上个月表示,共有2.7亿台活跃设备运行Windows 10操作系统,但其中很多都是免费升级,未能创造收入。

微软表示,该公司自主Surface品牌电脑仍是一个亮点。该公司表示,按不变汇率计算,Surface品牌电脑收入增长61%,首次在假期以外时间连续第二个季度超过10亿美元。

包括微软流行办公软件Office在内的部门销售收入增长1%,至65.2亿美元,但利润下降6.6%。

微软的一个强大增长引擎是Office 365,即其办公软件的云版本。Office 365的收入被计入了企业内部部署版Office业务中,而非计入其他云计算业务中。

该公司表示,Office 365的消费者用户数量同比增长79%,商业用户数量同比增长57%。

Office 365的用户增长是一个重要指标,因微软正努力向这些客户追加销售其他云服务。胡德表示,Office 365帮助带动了Azure的业务扩张。

微软表示,总体而言,公司第三财季净利润降至37.6亿美元,合每股收益47美分;上年同期净利润为49.9亿美元,合每股收益61美分。

收入同比下滑5.5%,至205亿美元;经调整后收入同比增长1.6%,至220.8亿美元。

微软预计第四财季收入将在217亿-224亿美元。

Jay Greene

发表在 未分类 | 发表评论