【技术干货】我们的项目是如何技术选型的

​

本文作者：上海驻云开发总监   陈昂

以下正文：

---

公司逐渐壮大，团队日趋稳定。作为一名陪着公司一块成长的一分子，我深感欣慰。蓦然回首，发现我们竟然有了诸多产出与成果。有平台，有工具，有产品，有项目。有些项目进行中，有些产品已夭折。但不管怎样，看着这么多已有成果，还是小小的骄傲了一下。然而骄傲之余，精心沉思，我们积累的太少，沉淀的不够。以前，我们就像是在打仗，为了生存，你死我活，兵贵神速，分秒必争。现在，我们多少可以喘一口气的时候，有必要回顾下，总结下，沉淀下了。

那么，今天就先回顾下我们之前这些项目的技术选型过程吧。

时间回到2013年，当时刚刚换了一份糊口的工作。一家广告公司，美女如云，帅哥成堆，有充足的时间和资源让你定位自己的性取向。然而胖子的一通电话让我没有时间再去思考性取向的问题了。他电话中对云计算一阵云里雾里的吹嘘，让我的小心脏顿时扑通扑通的久久不能平静啊。立马决定加入他的新公司，拥抱云计算，迎接新挑战。

一个月后，到了新公司，哦不，应该说到了兄弟公司，借位办公（新公司还没完全成立，办公地点也还没选好，这些都不重要了，重要的是新产品已经开始规划了）。挖了两个前同事立马开干，做一个可视化云设计平台，主要面向阿里云（国内云计算老大嘛，抱大腿嘛，当然要抱老大的大腿喽）。通俗的讲呢，通过这个产品，用户可以方便直观的设计出云资源架构。

产品有几个基本需求：

1.免安装

2.兼容iPad

3.拖拽操作

4.呈现的架构够直观

5.能够同步基础云资源（阿里云）

基本需求不多，但各个切中云计算痛点。发挥的余地还是比较大的。对于第一点，免安装，那么基本只考虑WEB方式了。

既然是WEB应用，就要先考虑五花八门的浏览器的兼容性。由于这个产品的客户比较面向技术，IE也就暂时不考虑兼容（不解释）。最后选了两款浏览器作为主要兼容目标：Chrome、Safari。

选好浏览器就是开发语言的选型了。JS肯定是必须的，另外，那么后端语言，零零总总一堆：PHP、NodeJS、Python、JAVA、ROR... 

• PHP是WEB霸主，有很多成熟的WEB框架

• NodeJS是新贵，本身就是JS语言，前后端基本不存在兼容问题

• Python语法够优雅

• JAVA够厚重稳定，但是开发慢

• ROR够快，但是比较适合MES系统

• ...

我们这个产品有什么特点呢：

• 面向云计算的设计和同步平台

• 前端有大量复杂的逻辑和计算

• 后端不需要太负责的逻辑支持

• 能够快速开发和产出，因为当时如果不及时产出，公司可能就死掉了（QAQ）

既然这样，我们直接先排除了JAVA、Python、ROR。后来在PHP和NodeJS之间犹豫了好久。最后考虑到PHP恶心的语法，考虑到NodeJS完美支持JSON，最后考虑到我们需要实时同步而NodeJS领域有个Socket.io可以完美支持，就选择NodeJS了（其实那些都是为了说服自己的理由，PHP毕竟还是很成熟的）。

接下来的事情就是选几个已经有很多轮子的框架或工具，帮我们造车。

• 由于前端需要Canvas，最后找了一个很不错的Canvas框架KineticJS（其实我们是先看到了KineticJS，再定了Canvas），KineticJS封装了丰富的Canvas组件，让我们可以以组件的方式操作画布，方便开发。

• 模板层我们选了轻量的Handlebars。

• 后端NodeJS层面选用Express

• MongoDB层面选用Moogoose来操作数据

• 由于前后都是JS，为了提高开发效率，强制大家都用Coffeescript（js的转义语言）来编写代码（几乎所有项目沿袭至今）

• CSS用Less，就像Coffeescript一样

• 项目构建采用Grunt

其实这些技术选型还是很盲目的，然而技术永远不可能有最好的，只有最适合的。虽然是盲目的选型，但是选型和推广的过程的确是痛苦的，不管团队是人多还是人少。世界上最难得的事情莫过于说服别人改变自己的习惯。比如推广coffeescript，有一个开发很排斥，一开始死活不愿用coffee写js，感觉这样不够正宗，他的一句话还让我快吐血了，是男人就不该戴套。不过私下里他还是尝试了coffee，也很发现了coffee带来的快感。

后来的事实也证明我们的技术选型带来了很大的优势。三个人，两个月就出了第一版，并参加了阿里云开发者大会，收获也不同凡响。后来又经过几个月雕琢，出了好几个版本。奈何当时阿里云API尚缺稳定，也不够丰富（当然我们也是对API深度使用了），我们只发布了一个设计版。

这里有必要发一下我们这个产品的简单部署架构。

架构很简单，同时，这个架构也是我用我们这个产品画出来的。其实这个产品还是有很多bug的，以及体验上的缺陷。

然而，这些都不重要了。我们度过了生存期，而且还带来了个意外的项目，为阿里云做一个VPC的可视化平台（这个平台现在你已经看不到了，放个图吧）

 

 

有时候事情的发展就是这样，做好了自己的本职工作，幸运就会降临，就像国足这次进入12强，赢得了牵动亚洲的计算题一样。

 

这个项目的技术选型和上面那个产品差不多，就不赘述了。需要提一下的是这个项目在部署阶段遇到拦路虎了。因为是阿里云的项目，部署环境理应是用阿里云资源，一开始的架构是这样的：

 

 

前面还是负载均衡，挂载两台机器，缓存服务采用阿里云的OCS，数据库我们尝试用OTS。

在部署的过程中，发现SLB无法透传Websockets，也就无法支持Socket.io工作，而Socket.io在这个项目中起了很大的作用。我们尝试着SLB从HTTP换成TCP模式（毕竟SLB对TCP模式是直接转发的IP），但也不行，当时没搞清楚是阿里云产品的问题还是我们配置问题（当然现在的阿里云SLB已经很完美了）。后来经过多次尝试，终于曲线救国，socket.io 改用polling的方式，不用websockets。另外为了充分发挥多核的性能，NodeJS也开启多个进程。但是为了满足Socket.io，要保证Session在同一进程，Nodejs每个进程就开启了不同的端口，前面通过Nginx 配置 IP Hash并反向代理到不同的NodeJS端口。如下图所示

再后来，发现OCS的Node SDK不稳定，就启用了OCS，直接换成了ECS搭建Memcached。

 

 

经过几个月的奋战，这个项目成功上线，来不及喘息，新项目又来了。

 

这次要做一个云管理平台，典型的MES系统。项目开始，技术选型这块就出现了矛盾。基本明确的是基础语言不变，后端还是NodeJS，数据库换成RDS。

但是前端的框架起了争执。之前的那些框架或工具明显不适用了，得选一个能够快速开发并且方便维护管理的前端框架做支撑，这时候AngularJS和EmberJS进入了我们的选择。一个是Google出品，上手快，但深入难。一个是社区项目，更面向生产，但不够轻盈。我坚持选择EmberJS，因为更加面向生产，也更加面向团队协作，不像AngularJS引入了很多新概念，学习成本更低。一个同事坚持Angular，他之前就用过，而且Angular更火一点。最后我做了妥协，毕竟不管哪个，对我来说都是新的。而如果团队里有一个有经验的人在，会更加可靠一点。

后来的情况是这样的，Angular配合着NodeJS带来了极速开发，项目一个多月就上线了（你没看错，是一个多月）。这个框架在公司也就火起来了（虽然开发还是不多）。这期间，我个人也对Angular上手了，感觉框架本身的理念还是很超前的，开发非常快，特别适合MES系统，如果你的系统是管理系统，BOSS系统，或是信息系统，用它，绝对没错。

公司这时候也逐渐壮大了起来，产品和项目也多了起来。一个产品或项目再也不是只有一个两个人奋战的情况了。团队成员之间的协作也变得日趋重要和紧密，程序需要解耦，团队协作同样也需要“解耦”。敏捷开发时代，前端程序是不可能等后端API都调试好了再进行开发的。这个时候就有人提出了“前后分离”这个词。这个词当下很火，阿里也在做这样的事情，只不过业务不同罢了。几个人坐下来一合计，感觉这事靠谱，做吧。接口规范定义清除，数据格式定义清除。后端无需关心前端的业务逻辑，只要保证好什么样的接口应该具有什么样的权限，应该如何传参，返回什么样的数据就行。校验不通过，按照既定的数据格式返回给前端。前端业务只需要根据后端的API返回数据做进一步的逻辑处理就行。前后端同步进行，没有完成的接口，前端通过Mockup调试，完成了就联调。直到现在，我们的前端妹子，还在说，“前后分离”大法好啊。

 

• 永远没有一招鲜的技术

 

永远没有一招鲜吃遍天的技术，也没有一招鲜的选型。因为业务的需求，我们接了一个外包。对方公司要求做一个CMS系统 + 开发者平台。如果不考虑其他因素，CMS系统我们可能就直接上Drupal啦，开发者平台就通过Angular +NodeJS实现。可是对方还有一个需求就是开发完成3个月内能够接手代码，而对方公司技术人员大多数是JAVA背景。为了能够让对方快速接手，我们做了如下的技术选型。

在这个模型中JAVA层只负责和客户的TOP数据接口打交道，然后通过提供RESTful风格接口为前端系统提供接口服务。其中CMS和开发者平台都是基于Angular打造。由于网站直接面向公众，更多也是静态页面，需要有更好的加载性能和SEO友好，所以通过NodeJS进行渲染，而NodeJS又和JAVA进行数据交换。

开发的过程，其实并不是太顺利。一方面因为对于CMS系统（业务复杂性很高）的不了解，我们等于说是从0打造，没用太多的轮子可用。另一方面，项目存在三方协作的问题，协调效率并不是太高。但不管怎样，项目还是顺利完成了。

 

• 新的挑战

随着业务的发展，公司想要对最早的架构云重新打造，让其上升到一个更高的高度。如果要用数字1表示一个产品是完整的，那么之前的架构云只能说是0.8。毕竟是公司初期的产品，也有很多产品外的压力因素导致我们没有做到1。不过公司今非昔比了，有充分的时间让我们静静思考下产品，我们有了更高的目标和要求，那就是把产品从0.8做到1，再做到5。基于这个目标，经过团队人员的讨论和商量，老产品维护成本太高，基础选型也不够成熟，我们打算对其进行重构。重构的第一关就是技术选型啦。结合之前的经验，我们认为，轻量级的框架会给我们带来更高的掌控性和稳定性。后端选了NodeJS，数据库采用Mysql。更多的工作是在前端。经过Demo尝试，SVG性能更好，开发起来也更加舒服。基于SVG选了Snap.svg（比较轻量的SVG工具）。在渲染层面，选了鼎鼎大名的ReactJS。ReactJS的VirtualDOM对于画布的渲染有着非常高的性能和可维护性，也能方便的做到组件化和模块化，进一步降低开发成本。以下就是我们新的架构云技术选型

新的架构云已经如火如荼的进行中了，几个月后，大家将会看到漂亮的第一版。敬请期待~~~

好啦~本文到这里就结束了，同时，如果喜欢我们的话就赶紧订阅我们吧~~~每天定时推送新鲜干货~~~也可以关注我们的微信公众号：架构云专家频道 每天同步更新哟~~~