前言：这篇文章写作过程断断续续持续了两个月，终于写完了，最近事情有些多。
这次技术会议的主办方虽然是阿里巴巴，但是还有很多其他的互联网企业，比如百度，新浪，腾讯，盛大，360，小米。
会议共有两天，主要面向互联网技术，参与者也大多是互联网公司从业者。人还比较多，讨论也比较活跃。
我主要参与的是aDev(应用架构和后端技术)，这里简单总结一下：
1、SOA的落地。
记得Infoq上一篇文章曾说过：大意是，当一个技术大家不再热烈的讨论它的时候，说明他已经在工作中真正的发挥作用（当然也可能被淘汰），SOA应该是如此的。虽然各大网站对它的讨论热度不在，但是从这次技术会议中，随处可见SOA的身影。很多公司的交流都涉及到这一块，包括淘宝，米聊，新浪，一淘等等。就像林昊在一篇文章中谈到的：“SOA在大网站中已经落地，而不像企业领域中宣传的那么虚”。
在企业领域，提到SOA，往往意味着大量复杂，昂贵的工具。SOA更多的是一种思想，即便是没有工具，或者是简单的工具，也能够让它为系统设计服务。可喜的是现在确实有非常优秀的构建SOA系统的开业软件，比如这次大会是提到的thrift，zookeeper等。
这一块我最近要深入学习一下，并且也能够应用到我们的工作中。
2、服务的无状态
我接触SOA的概念有很长时间，以前其实不是十分的理解服务的无状态的特性是什么含义，最近有点体会。小米的一个分享中提到，要看服务是否无状态的，就看他是否可以被kill -9。后来有人提问时他举例说了一下，比如数据室保存在进程中而不是数据库中，如果进程重启，那数据就丢失了。
这可能是无状态的一种体现，但我认为，无状态更主要是体现在服务提供者不应该记录并依赖调用者的上下文信息。有状态的几个实例：
1、调用者调用了一个某一机器提供的服务，那么，下一次他必须也要从这台机器获取服务；
2、调用某一服务之前，必须调用另外一个服务。
但是现实世界是有状态的，要实现无状态的服务，基本有两个方法，一个是类似RESTful，将状态信息转移到客户端；一个是建立一个分布式的缓存系统，将状态信息全部放到缓存中。在构造无状态服务这一块，函数式编程语言天生就有优势，无状态时它的一个特点。其他语言只要采用一定规范（比如禁止使用全局变量），也可以编写无状态的服务。
无状态服务的最大的目的应该是便于系统的水平扩展，同时也能够简化服务调用。
我们目前的系统要转向无状态可能要伤筋动骨。我们的很多的api都是有状态，组粒度的，这样的本来目的是为了简化调用者开发，最大的重用代码。有一段时间考虑主备热备份时考虑过通过同步内存和数据库来实现，但是后来发现内存中的很多状态信息很分散，包括api中都是有状态信息的。如果说我们要采用无状态服务的，一个出发点很可能是系统热备：无状态的服务在加上类似于
MemcacheDB，Redis数据库。状态全部保存在数据库中，并且通过数据库进行同步。
我们的业务特点是，并发不会太大，但是逻辑复杂。这可能是我们和互联网业务不同的地方。我们基本不会用无状态特性来水平扩展。
3、组合服务，流程，交互
组合服务就是一个服务会调用多个基本服务，通过封装来提供更粗粒度的服务，以达到重用，方便开发的目的。问题是组合服务中可能会记录服务调用的进度，特别是如果这个组合服务还涉及到和调用者的交互，如何保持无状态的特性？这个问题问过小米的嘉宾，不过没有具体回答，参会者有人提出米聊逻辑不会这么复杂。
确实如此，互联网业务的一个特点是逻辑简单，但是并发量大；而企业领域的一个特点是逻辑复杂，但是并发量一般不大。后来又参加天猫的一个分享，发现电子商务的逻辑也够复杂，应该算是互联网中的另类。而我们的业务特点是逻辑中很多地方都涉及到和用户的交互，即可能在流程的任意阶段，收到用户的某些事件。
一个组合服务如果不涉及到和用户的再次交互，那么保持无状态会简单一点，按照和用户的交互点对组合服务进一步分割是一个思路。还有一个思路是后端只提供基本服务，组合的调用，把它放到前端，类似于RESTful，将状态信息转移到客户端。
分享中涉及到目前一些开源的软件如thrift，消息队列产品，zookeeper等。
4、去c化
能够用脚本语言去完成的，尽量用脚本语言完成，可以提高开发的效率及质量。这是从新浪开发者演讲得出的一个结论，也是最近我们正在进行的一件事情。之前我们公司的程序员主要以C为主，即便是做业务开发也是基本用c（也会用java）。结果就是c程序开发成本和维护成本相对较高，如果业务逻辑复杂的话，更难处理，目前我们在linux服务器开发上尝试使用python，嵌入式开发尝试使用lua。已经尝试了几个项目，目前来看效果不错。
和这个相关的一个分享是ngx_lua。Nginx 的lua扩展，总体思路应该是很“通过将lua解释器集成进Nginx，可以采用lua脚本实现业务逻辑，由于lua的紧凑、快速以及内建协程，所以在保证高并发服务能力的同时极大地降低了业务逻辑实现成本。”。lua的运行效率相对其他脚本语言可能更好。缺点正如分享所说：基础设施不是很完善，开源库不够丰富。有人提问为什么不考虑python，ruby等其他脚本语言，分享者的回答是这些语言不支持协程，所以直接就不在考虑范围之内。python应该是支持协程，自带的yield虽然实现协程受限较多，但是第三方的实现，比如greenlet还是比较成熟的，这一块我使用的还是比较多的。我分析没有考虑python的原因可能是python的协程实现和nginx集成有难度，同时运行性能也没有lua好（个人猜测，对nginx不是很熟悉）。可惜后面没有机会确认。
如果python可以的话，可读性，语言表达力，基础设施完备性相对lua优势更大。
nodejs:适合IO密集，逻辑不复杂的系统。如果逻辑复杂，用回调描述逻辑是反人类认知的。这里使用协程更好。javascript中也有很多这方面的库。印象中老赵也开源了一个。
5、小小的遗憾
和我们领域接近的杭州的大公司，比如华为，海康，华三等基本上都是在这种技术交流中缺席的，比较遗憾。
总结：
两天时间学了不少东西，这里只记录了一些和我最近比较有共鸣的一些想法。同时，SOA和去c也是我最近的一个方向。