如今，许多初创企业和成熟企业都选择Ruby on Rails进行Web开发，例如Basecamp，GitHub，Dribble，Airbnb等公司均使用此框架构建网站。

那么，为什么要使用RoR呢？

Ruby on Rails简介

统计数据

首先，让我们看看关于Ruby on Rails框架的数据:

根据BuiltWith的数据，超过523339个网站是用这种技术创建的。
在GitHub上有近4000名程序员为RoR的发展做出了贡献。
Ruby on Rails拥有超过45000颗GitHub星。
Arc指出，一位Ruby on Rails高级开发人员在北美的平均时薪是121-140美元。

Rails的简短历史

David Heinemeier Hansson于2000年代初创建了Ruby on Rails，当时他在开发名为Basecamp的项目管理工具。

RoR框架以其快速、简便的web应用程序开发和部署而著称。因此，Ruby编程语言的创建者Matsuki Yukihiro Matsumoto将此工具称为“ Ruby的杀手级应用”。

Rails的基本原理

Ruby on Rails是一个广泛用于Web应用程序开发的开源框架。它在Ruby上运行，专注于简单性和完善的输出。

它的核心原则使企业家可以减少花费。同时，开发人员可以更快，更轻松地完成任务。

原理：避免重复代码（DRY）

该规则指出，每个代码段都需要在系统内进行唯一，明确且权威的提交。它使应用程序代码更清洁，错误更少。此外，开发人员可以重组代码或将其重构。

原理： 约定优于配置

这个概念假设您使用的系统、库和语言在默认情况下假定了许多逻辑情况。程序员需要指定web应用程序的一些非常规方面，而不是每次都创建新规则。因此，编程变得越来越简单高效。

使用Ruby on Rails进行Web开发的利弊

当涉及到web应用程序开发时，有各种各样的工具可供选择。为了做出正确的决定，您应该考虑学习曲线、可伸缩性、托管需求、安装的方便性、文档等因素。

Ruby on Rails的优点

1.安全性

近年来，网络安全问题已成为企业面临的一个严重问题。根据Cybint Solutions公司的数据，令人震惊的是64%的公司都面临过网络攻击。与此同时，62%的公司成为网络钓鱼和社会工程攻击的受害者。

从下图可以看出，后一类网络安全问题主要针对SaaS、金融机构和电子商务平台。

这些统计数据说明了为什么您未来的解决方案的安全性至关重要。

幸运的是，由于其内置机制，Ruby on Rails可以保证您的网页或应用程序不受常见漏洞的影响。有了这个框架，您的web产品将免受以下威胁:

跨站脚本攻击
SQL注入
跨站请求伪造
不安全的直接对象引用或强制浏览。
2.使用简单

RoR以直观，简洁和易于理解的语法而闻名，这对程序员来说意味着更高的可用性。

Ruby on Rails开发人员编写的代码更少。因此，创建web应用程序的过程变得更快。由于框架的可读性，对于开发人员来说，代码变得更容易理解了。

此外，由于项目遵循相同的规则和原则，程序员可以在任何开发阶段从一个Rails项目转移到另一个Rails项目。

3.开发速度快

该框架提供了大量名为gems的免费开源库。它们扩展或修改了Web应用程序的现有功能，并为开发人员提供了常见问题的解决方案。

今天，Ruby gems的数量已经超过了158700 +，下载量超过了480亿次。

此外，还有一些库扩展和实用程序类，它们构成了Active Support，负责开发Rails应用程序和技术本身。

快速开发是创业公司选择Ruby on Rails的关键原因之一。这个框架加快了MVP开发过程，即使在预算有限的情况下也可以创建高质量的Web产品。

4.社区

Ruby on Rails有一个充满活力的社区。它的活跃成员创建Ruby on Rails专用的网站、论坛和聊天室，帮助开发人员从遇到类似问题的其他程序员那里找到专业答案，并提出解决方案。

此外，社区成员还不断编写指南、手册、课程和其他教育材料。

社区托管了RailsConf，这是RoR开发人员的最大聚会，可以与该框架的其他粉丝分享经验。

5.轻松实现业务逻辑

使用Ruby on Rails可以很容易地在web应用程序中实现复杂的业务逻辑。假设您需要API。应用此框架的开发人员将很快创建它。你唯一要做的就是添加一个像Vue或React这样的前端框架，仅此而已。

6.与前端框架的兼容性

如今，React、Vue和Angular等前端框架越来越受欢迎。由于RoR易于集成，这些工具被广泛地与Ruby on Rails一起使用。您可以采用任何您喜欢的框架进行快速开发。

Ruby on Rails的缺点

1.运行速度和性能

应用程序的成功通常取决于这两个参数。客户通常希望Web应用程序能够快速加载。

谷歌的研究显示了每秒钟的延迟如何减少页面的访问量的。

有时候，Ruby on Rails的运行速度有很多不足之处。对于不到数百万用户的小型应用程序来说，这已经足够了，但在构建一个可靠的web项目时，这可能会成为一个问题。

然而，2019年8月发布的Ruby on Rails 6.0版本涉及了这个主题。新功能允许开发人员使用两个数据库在它们之间进行切换，从而提高了性能。

2.缺乏灵活性

由于组件和模块之间存在严格的依赖关系，因此Ruby on Rails是常规Web应用程序的理想解决方案。但是，当涉及具有特定功能的应用程序时，自定义可能会充满挑战。

配置路由，数据库迁移和其他元素会减慢Web应用程序的开发过程。

3.较低的知名度

在过去的几年里，Ruby on Rails的受欢迎程度一直在下降。谷歌Trends提供的统计数据表明，人们对这个框架缺乏兴趣。

尽管开发人员和支持社区的数量在增加，但该技术并未像PHP的Laravel或Python的Django那样广泛使用。可能的原因之一是其陡峭的学习曲线。通常，精通Ruby on Rails的开发人员都知道一种或两种编程语言。

对于企业所有者来说，这意味着与寻找PHP、Java或Python web公司相比，雇佣一个有经验的Ruby on Rails开发机构可能是一个相当具有挑战性的过程。与此同时，他们会得到更有经验和技术的专家。

Ruby on Rails在Web开发中的使用

让我们仔细看看最适合Ruby on Rails框架的项目。

初创企业

Ruby on Rails是初创公司最适合使用的技术之一。它在构建原型和开发MVP时得到了应用，这使得Rails备受推崇。

像GitHub、Twitter、Airbnb和Dribbble这样的流行平台最初都是用Ruby on Rails创建的。

电子商务

使用前面提到的gems，您基本上可以实现电子商务平台可能需要的任何功能。

Shopify、Fiverr、Groupon和Etsy最初都是基于Ruby on Rails的。

SaaS

在构建SaaS产品时，安全性是重中之重，而Ruby on Rails可确保Web产品的安全性。在此框架内，有很多预防措施来保护数据，包括使用大量gem进行身份验证和增加密码长度，多个内置加密库，跳过伪造请求以及使用强参数。

Basecamp，Zendesk和GitHub是使用RoR构建的最著名的SaaS应用程序。

最后

总之，Ruby on Rails是一个高效的、可伸缩的、安全的web开发框架，它可以帮助您构建任何类型的产品:从电子商务平台到SaaS解决方案。但是，RoR也有一些缺点，应该加以考虑。

轻量级的报表、文档可以有效地帮助敏捷团队更好的将工作可视化、辅助和客户的沟通、清晰的展示进度并且对风险进行把控，对项目管理有很好的作用。在过去的项目管理经验中，个人认为有五类图表是项目经理需要了解并且可以在日常工作中频繁使用的。

敏捷的价值观强调可工作的软件更加重要，但也不能否认文档的价值。

燃尽图 ( Burndown Chart )

燃尽图是敏捷项目中最频繁使用的一类图表，它是在工作完成前对于进度的一种可视化表示。我们经常会利用迭代燃尽图来监控用户故事是否如期进行，当然也可以利用Feature燃尽图来监控MVP的完成情况。如下图：

该图横轴是时间，纵轴是剩余的用户故事点，灰色线是按照团队平均速率用户故事应该被完成的情况（水平部分是周末），蓝色线是实际情况。通过此图我们可以很清晰地看到该迭代团队的开发速率高于期望并且差距不是很大，项目处于很健康的状况。如果蓝线一直高于灰线或者蓝线偏离灰线太远，项目经理就需要注意了，有可能的原因包括迭代计划不合理、团队开发速率出现了问题等，这会导致团队在迭代后期Backlog不够或者迭代结束不能正常完成计划的点数，所以需要项目管理者和团队一起分析具体的原因并且尽快采取措施。

速率表 ( Velocity Chart )

敏捷开发以迭代为周期开展工作，在每个迭代开始之前都会按照团队的平均Velocity来安排迭代计划，所以持续地关注团队的Velocity便于更准确地了解团队的交付能力，更合理的做迭代计划。项目经理通过Velocity表可以从总体上分析团队的开发速度是否正常、迭代计划是否合理以及对于剩余的Scope是否有交付的风险。如下图：

该图表横轴是迭代，纵轴是完成的用户故事点数，绿色表示实际完成的故事点数，灰色表示按照团队能力应该完成的故事点数。通过该图我们可以看到绿色和灰色虽然有时不同但一直比较接近，团队处于很健康的状况。如果绿色和灰色某一次或者总是差距很大，有可能的原因包括某一段时期的feature复杂度提升、团队内频繁的人员调整或者各类会议增多导致的开发时间减少等，这时候项目经理就要意识到团队可能有交付风险或者需要调整迭代计划了。

甘特图 ( Gantt Chart )

甘特图也叫横道图，是项目管理领域最常用到图表形式，一般用来展示活动或者事件随着时间和费用的变化，通常会包括活动清单、活动日期、进度期限和每天的进展。在敏捷项目管理中，我们可以借助甘特图来可视化某个特定项目（包含一系列的子活动）的进展。如下图：

该图拿数据迁移这一事件为例，横轴是时间，纵轴是完成数据迁移需要的一系列活动，相同颜色代表同样的活动，灰色表示还没有完成的工作。通过该图可以看到数据迁移的大部分工作已经完成，只剩下最后的POC2的数据分析，并且能看到各项子活动的实际耗时，便于之后类似活动的计划和安排。在敏捷项目中我们还可以借助甘特图来管理Epic用户故事的进展、预算的花费情况等，如果发现某些子活动没有进展，或者消费超过预算太多，项目经理就要考虑采取一些措施推进某些子活动或者消减某方面的投入了。

日报 ( Daily Update )

以上三类是通用的一些图表，很多项目管理软件已经支持，比如 Jira, Mingle 可以自动生成燃尽图和速率表，甘特图有专门的绘制软件。而日报是我们在离岸交付项目长期摸索的过程中使用最频繁也最重要的一个图表，对于每日的沟通非常有用。如下图：

该图分为三大块，首先是每天的用户故事进展，然后是已有的Backlog的情况，最后是开放性问题，绿色背景是每天内有变化的故事卡，黄色是由于各种原因被block的故事卡，该报表的目的不是为了汇报工作，而是为了让异地的团队和客户对于每天的进展都能一目了然。虽然我们有项目管理工具比如Jira等，但是对于离岸团队来说，通过这样的图表更能清晰地看到每天的变化，让不和我们坐在一起的客户增加信心，也便于我们把遇到的blocker可视化出来。

红黄绿报告 ( RAG Report )

RAG是Red，Amber，Green的缩写，该报告采用了和交通灯一样的呈现方式，简单易懂，可以用来做项目、人员等的健康度报表，拿项目健康度报表举例，项目经理可以按照自己项目需要关注的维度制定该表，然后定期监控每一项是否健康，对于敏捷团队来说，一周一般就可以了。如下图：

该图横向是项目是否健康需要考虑的几个维度，纵向是时间，每一个单元格里的颜色采用了RAG，红色表示该项出现了严重的问题，如果不尽快采取措施，会有不能接受的影响；黄色表示有一定的影响，团队已经在通过一些方案减小影响；绿色表示该项如期进行。通过该图可以看到该项目在过去的三周没有严重问题，总体来说比较健康，People方面虽然在第一周遇上了一些问题但是通过采取措施已经完全解决，Legal方面目前还在尝试解决。如果发现有红色出现或者某项持续绿色，项目经理就需要马上找相应人员采取措施了。

总结

任何一个报表都只是辅助工具，如果绘制或者更新报表的过程非常繁琐，那么这样的报表读起来也一定不会轻松。本文推荐的五类报表是我在敏捷项目管理过程中认为简单易用并且很有帮助的一些报表，通过使用他们，可以辅助我们管理进度、高效沟通、预知风险。当然，除了本文提到的五类报表，项目经理还需要了解一些其他的报表，比如基本的财务报表等，这部分跟团队开发模式没有太大的关系，所以没有加入到本文的范围。

1. MVC
2. 服务拆分
3. 微服务架构
4. 领域驱动设计

总结

来腾讯之前在前公司做了3年的后端开发, 经历一款SaaS产品从0到10(还没有到100, 哈哈哈)的过程, 3年间后端的架构逐步演变, 在微服务的实践过程中遇到的问题也越来越多, 在这里总结下.

产品是一款服务于人力资源的SaaS在线服务, 面向HR有Web Android/iOS 小程序多个客户端, 后端采用RESTful风格API来提供服务. 主要使用Python语言, 方便快速迭代.

架构的演进经历了4个大的阶段: 1. MVC 2. 服务拆分 3. 微服务架构 4. 领域驱动设计.

1. MVC

项目刚开始的时候, 后端同事不超过5个, 这个阶段主要的工作是实现产品的原型, 没有太多的考虑架构, 使用Django来快速实现功能, DB的表结构设计好之后, 抽象出功能View, 由于产品设计也很不完善, 后端需要很多的预留设计, 避免产品逻辑的变更带来整个表结构的变动, 在这个阶段代码上最重要的是确定适合团队的代码规范, 代码检查规则.

整体上架构如上图, Nginx负责负载均衡, 分发流量到多个Django服务, Django处理逻辑, 需要异步任务就交给Celery, 然后数据量比较大的地方使用Redis做缓存. 同时还有实时消息通知的需要使用了Nginx Push Module.

问题与优化方式:

1. Django并发性能差 使用uWSGI Master+Worker 配合 gevent 携程支持高并发
2. Redis连接数过多 使用redis-py自带的连接池来实现连接复用
3. MySQL连接数过多 使用djorm-ext-pool连接池复用连接
4. Celery配置gevent支持并发任务

随着开发的功能越来越多, Django下的app也越来越多, 这就带了发布上的不方便, 每次发布版本都需要重启所有的Django服务, 如果发布遇到问题, 只能加班解决了. 而且单个Django工程下的代码量也越来越多, 不好维护.

2. 服务拆分

随着后端团队的壮大, 分给每个同事的需求也越来越细, 如果继续在一个工程里面开发所有的代码, 维护起来的代价太高, 而我们的上一个架构中在Django里面已经按模块划分了一个个app, app内高类聚, app之间低耦合, 这就为服务的拆分带来了便利. 拆分的过程没有遇到太大的问题, 初期的拆分只是代码的分离, 把公用的代码抽离出来实现一个公用的Python库, 数据库, Redis还是共用, 随着负载的增加, 数据库也做了多实例.

如上图, 服务之间尽量避免相互调用, 需要交互的地方采用http请求的方式, 内网的调用使用hosts指向内网地址.

问题与优化方式:

Nginx Push Module由于长时间没有维护, 长连接最大数量不够, 使用Tornado + ZeroMQ实现了tormq服务来支撑消息通知
服务之间的调用采用http的方式, 并且要求有依赖的服务主机配置hosts指向被调用的地址, 这样带来的维护上的不方便. 以及在调用链的过程中没有重试, 错误处理, 限流等等的策略, 导致服务可用性差. 随着业务拆分, 继续使用Nginx维护配置非常麻烦, 经常因为修改Nginx的配置引发调用错误. 每一个服务都有一个完整的认证过程, 认证又依赖于用户中心的数据库, 修改认证时需要重新发布多个服务.

3. 微服务架构

首先是在接入层引入了基于OpenResty的Kong API Gateway, 定制实现了认证, 限流等插件. 在接入层承接并剥离了应用层公共的认证, 限流等功能. 在发布新的服务时, 发布脚本中调用Kong admin api注册服务地址到Kong, 并加载api需要使用插件.

为了解决相互调用的问题, 维护了一个基于gevent+msgpack的RPC服务框架doge, 借助于etcd做服务治理, 并在rpc客户端实现了限流, 高可用, 负载均衡这些功能.

在这个阶段最难的技术选型, 开源的API网关大多用Golang与OpenResty(lua)实现, 为了应对我们业务的需要还要做定制. 前期花了1个月时间学习OpenResty与Golang, 并使用OpenResty实现了一个短网址服务shorturl用在业务中. 最终选择Kong是基于Lua发布的便利性, Kong的开箱即用以及插件开发比较容易. 性能的考量倒不是最重要的, 为了支撑更多的并发, 还使用了云平台提供的LB服务分发流量到2台Kong服务器组成的集群. 集群之间自动同步配置.

饿了么维护一个纯Python实现的thrift协议框架thriftpy, 并提供很多配套的工具, 如果团队足够大, 这一套RPC方案其实是合适的, 但是我们的团队人手不足, 水平参差不齐, 很难推广这一整套学习成本高昂的方案. 最终我们开发了类Duboo的RPC框架doge, 代码主要参考了weibo开源的motan.

4. 领域驱动设计

在这一架构中我们尝试从应用服务中抽离出数据服务层, 每一个数据服务包含一个或多个界限上下文, 界限上下文类只有一个聚合根来暴露出RPC调用的方法. 数据服务不依赖于应用服务, 应用服务可以依赖多个数据服务. 有了数据服务层, 应用就解耦了相互之间的依赖, 高层服务只依赖于底层服务.

在我离职时领域驱动设计还在学习设计阶段, 还没有落地, 但是我相信前公司的后端架构一定会往这个方向继续演进.

总结
架构的设计, 技术的选型, 不能完全按照流行的技术走, 最终还是服务于产品, 服务于客户的需求. 设计过程中由于团队, 人员的结构问题, 有很多的妥协之处, 如何在妥协中找到最优解才是最大的挑战.

Service Mesh这种新一代的微服务架构正在成为主流, 虽然现在的工作与微服务无关了, 但是也还会继续关注学习.