2015年工作总结-CSDN博客

2015年即将过完，写一下工作总结。

一、项目总结与反思

企业应用中的服务集成

年初的时候，我的工作主要集中在我们产品与另一款被称为 DMA （动态媒体应用，不是直接内存访问）的媒体服务器产品之间的集成功能上。这些集成的功能包括当一个 DMA 集群中的一个节点崩溃时如何做故障转移等等。

其实一套企业应用解决方案有时也是一个分布式应用，其中包含了多种服务。但是企业应用服务之间的集成的方式有时显得很“老套”、“传统”。企业应用中的各个服务往往各自为战，每个服务调用方都需要处理分布式应用中会遇到的各种问题，诸如故障转移。这是因为企业应用对伸缩性要求较低，所以这些对于分布式应用很重要的基础服务并没有被作为应用运行平台的一部分而实现。而互联网应用会将服务治理、路由、数据平台等等这样的基础功能作为一个平台来统一实现。企业应用的开发人员也都知道高可用，但是却不知道朝哪个方向前进，如何前进。所以互联网企业对企业应用开发人员在技术上有所歧视也是可以理解。

我经过这一年的工作和对微服务架构的学习，在我所工作的项目中发现了更多的服务集成方面的问题：

数据库共享：在我们的产品和 DMA 集成之后，DMA 会直接访问我们产品的 LDAP 数据库。按照微服务架构的几点原则中就有一点是禁止这种设计的。事实也证明了这种设计到这里各式各样的问题。原因也很简单，我们失去了对自己数据库中数据完整性的控制。
服务配置信息分散管理：在互联网或者新的企业应用中，一个服务相关的信息，如地址、版本、状态等都是存储在一个专门的数据库中，比如基于 Apache Zookeeper 开发的服务注册查证机构。但现在在我们的架构中，这样的信息是每个应用自己管理。当然这么做是有历史原因，否则那时的设计就太有超前性了。但是，令人担心的是，现在的公司中的技术人员并没有意识到这种设计存在的问题。
服务粒度过粗：这是 SOA 时代必然存在的设计问题。但是同样也鲜有人意识到这个问题。
服务版本混乱：使用 Accept 和 Content-Type 这两个 HTTP header 区分服务的版本

让使用老版本 JBoss 的项目支持 WebSocket

我们的项目可以算是个技术上老掉渣的项目了，还在使用 JBoss 4 作为应用的运行环境。吐槽的话不多说，工作还要继续。架构、技术无法大改，为了是现有产品支持 WebSocket，最快捷的方法就是使用 Netty 支持 WebSocket。对于原有的 HTTP 服务，则通过 Netty 代理给 JBoss。

坑爹的 ApacheDS

项目中使用 OpenDS 已提供 LDAP 存储服务。虽然选择 LDAP 存储服务是早期不合格的架构设计给现在挖的坑，但是因为骨感的现实，这个坑暂时还填不上。OpenDS 要收费，领导层自然出于节省成本的考虑让我们选择其替代者。选择不多，ApacheDS 是其中一个。但不用不知道，一用吓一跳。ApacheDS 这个东西 bug 也很多，我们在使用过程中就发现了：

ApacheDS 底层使用了一个叫 Apache Mavibot 的项目来实现 MVCC (Multi Version Concurrency Control) 存储。我现在已经记不清这个数据结构的实现细节了，即便是 B+Tree B-Tree 什么的也记不清了。

ApacheDS 项目的发展

一个上海 Intel 专门从事开源项目研发的哥们因为在 Apache JIRA 上看到了我们的提问而给我打电话，也聊到了 ApacheDS 这个项目。他说到 ApacheDS 这个项目目前主要是为 Hadoop 提供 Kerberos 认证服务。目前 Mavibot 这个项目 bug 多得也让他们累觉不爱。未来的计划是基于想 Zookeeper 这样的分布式存储提供树状存储的基础实现。

支持 NTLM 的负载均衡器

为了使产品的架构向微服务方向转变，我们需要选择一个反向代理产品，以实现外部服务之间的负载均衡，内部服务之间的服务查找路由等功能。因为企业应用在伸缩性方面要求相对简单，所以只需要考虑 HTTP 和 TCP 层面的负载均衡。我负责了技术调研。这似乎不是一件难事，但是如果考虑到公司各个产品大量使用的 NTLM 认证协议，那选择范围就不大了。NTLM 协议的特点是虽然认证信息是通过 HTTP、LDAP 这样的应用层协议传输，但是 NTLM 协议也同样会关注 TCP 的一些情况。具体来说就是 NTLM 认证会话必须是在同一个 TCP 连接里完成，否则便会失败。基于 HTTP 的 NTLM 认证过程通常是这样的：

-> 普通请求

<- 401 Unauth Response

-> T1（请求）

<- T2（响应）

-> T3（请求）

<- 200 OK Response

经过调研我发现，Nginx 没有哪种配置可以使其很好地支持 NTLM 协议。HAProxy 的 HTTP Tunnel 模式可以很好地支持，即前后端的连接会保持唯一性。但是，我们的负载均衡的技术选型除了要考虑 NTLM 协议以外，还要考虑一些来自特殊部门的安全方面的要求。这些要求往往需要一些自定义的开发工作，所以 HAProxy 也被排除出去。因为对它的自定义开发没有经验，且会引入新的语言，而且还有协议方面的顾虑。

最终还是选择了以 Netty 为基础开发负载均衡器。目前项目在年底开始向支持完整的 HTTP 和 TCP 路由配置的方向发展。

从事项目管理

五月份公司开始了一个新的解决方案的研发工作。这个新方案涉及到了两个服务器端产品和三个终端产品，整个团队分散在四个国家。我主要负责7月份的时候因为工作的原因去以色列出差工作两周。工作间隙领略了耶路撒冷古老城墙、雅法老城、马萨达遗址。当然也去死海里面泡了泡。

以色列其实是一个很安全的国家，尤其是远离巴以边境的地方。街上不时能看到持枪的士兵，不过那是因为以色列士兵即便在休假的时候也枪不离手。以色列人还是很友好的，除了刚下飞机被便衣问了几个简单的问题，其实我觉得也是例行公事。

出国工作还是很锻炼英语的，一天到晚都是不停滴说英语，自己在工作方面英语是够了，但是在非工作方面还是有些费力，主要是词汇量还是太有限。好在自己脸皮厚，听不懂了就让对方拼一下单词，手机一查也就懂了。

更加坑爹的 Calendar Proxy 项目

我们有一个功能叫 Calendar Proxy，这个功能是以 MS Exchange、Office 365、Google Calendar 等日历服务为基础，提供一个通用的日历 API，并提供和我们公司业务相关的一些额外数据。这些数据的细节就不说了。总体而言，这个功能实现起来并不复杂。美国研发部的一个老外实现了这个功能。结果是这个老外吹得比天高，花了半年多做的却渣一样的烂。无奈我们产品还必须集成这一功能。吐槽的话就不再说了。总之在浪费了大量时间，加了N天班之后，我最终花了两天实现了性能高了至少一个数量级的新实现。

从好的方面看，这个不靠谱的功能让我有机会去实践 Wireshark，加深了对 TCP 的理解，认识了 NTLM 协议（虽然用的越来越少），再次有了一个实践 Netty 的机会。

现在用 Netty 实现 Calendar Proxy 的工作依旧在进行中。

二、学习

技术分享

年初第三次读了一遍《Java并发编程实战》，之后做了若干关于并发编程的技术分享。第一个题目是整体介绍了 Java 并发和异步编程，之后介绍了一些具体的内容，包括“Java 线程池的构造函数的参数详解，以及内部实现原理”、“Java 线程池中的异常处理”、“线程饥饿死锁”、“Schedule 线程池的实现”、“Java 8 Stream”、“分布式技术概述”、“微服务概述”。

推动工程师文化建设

年初的时候给领导提议加强跨部门的技术交流。主要通过定期的技术分享活动、培训、对各自产品的介绍，等等的形式加强工程师文化的建设。同时可以分享各部门已有的成果，提高工作效率，降低研发成本。写过邮件，也找领导谈过，但可惜这个提议最终还是石沉大海。

读过的书

《Java 并发编程实战》这本经典的书自然不必多介绍。《大型网站技术架构》和《大型网站系统与Java中间件开发实践》是大型网站技术体系入门的好书，我只读过一遍，接下来我会再读一遍，并写下总结。

我现在在读的是《深入理解Java虚拟机》，边读边写总结，相信这么读一遍的效果应该相当于读两三遍。

《Java应用架构设计》的副标题是“模块化模式与OSGi”，OSGi 这个技术只能算单个应用的一种候选技术，而不是大型系统或网站的主要技术。但是这本书提到的模块化设计的一些思想和技术还是值得思考的。这本书整体的水平不如其它几本书，但是也可以已读。

对容器技术的学习和对云计算的思考

目前产品的传统软件的形态已经暴露出太多缺点。向云计算转型并不是什么噱头，而是实实在在的必行之路。从14年开始火爆的容器技术为传统软件的转型铺平了道路。在年初的时候，自己不断地与同事和领导提到容器化的转型方向。最终产品的将部署在公有云或私有云上。如果是公有云，可以通过 AWS VPC 之类的方式连接到内网。从而，通过云计算技术，大幅降低软件的运行、部署和维护的成本。

自己预研了 CloudFoundry、Docker、Mesos、Kubernetes 等技术，首先否定的是 CloudFoundry，然后是 k8s，原因是还不成熟（当然，过去了小半年之后，k8s 有了很多新的发展，有一些公司，比如 eBay 也开始尝试大规模使用 k8s）。最后，将精力集中在了 Docker 和 Mesos。

转载于:https://my.oschina.net/lifany/blog/534415