不需要投入金钱和时间，可以准备个人开发应用程序的服务器端环境的方法是什么？

3 年 ago

清, 扬

2 minutes

这篇文章是Sansan Advent Calendar的第三天。

假设

即使个人开发应用，我还是认为总会有一些需要服务器端的机会。然而，我更想专注于应用开发，尽量不想在服务器端花费太多成本。在这种情况下，应该怎么办呢？

基本上

でもサーバーサイド用意したい

这是在假设的基础上讨论简单地准备服务器端环境的情况。

创作的应用程序等

最近我有点懒散放置了，但是我们之前发布了以下这些应用。这些个人应用都是由我们两个人开发的，在注重应用的同时，也辛苦准备了服务器端。在瞬间最大风速下，即使有约1000个请求/秒的访问，也没有出现任何负载等问题，基本上可以正常运行。

秘密的相册（照片管理应用程序）
https://itunes.apple.com/jp/app/himitsunoarubamu…/id662735705?mt=8

秘密的相册是一个照片管理应用程序，可以在iOS设备上使用。您可以通过此应用程序保存和组织您的照片，以及进行编辑和分享。请点击此链接以在iTunes上获取此应用程序。

猫咪小镇（一个模拟城市建设游戏）
[在中国App Store下载链接]：https://itunes.apple.com/jp/app/nyankotaun/id845923130?mt=8

准备服务器端环境有哪些好处？

有时候，实际上确实有不需要的选项。根据可用时间的长短来看，我认为将应用程序设计成完全依赖客户端也是可以的选择。就我个人而言，在准备服务器端并在应用运营中感到高兴的方面大致如下：

1. 可以发送推送通知

只使用本地通知而不使用服务器端进行用户召回的试验，在成本效益上也是一个不错的选择。例如，只在应用程序连续3天未启动时发送类似”希望你回来，喵~”的通知，这是仅通过客户端实现的可行方案。

iOS的本地通知·UILocalNotification的设置整理

然而，为了执行诸如在更新应用时发送通知、仅在进行特定活动时发送通知、在其他用户对某事采取行动时发送通知等措施，仍然需要在服务器端做好相应准备的手段。

可以实时进行应用程序的微调

为了在不影响用户体验的情况下最大化收益，需要通过实时调整来确定以什么组合和广告进行投放。如果广告投放后收益微妙，为了优先考虑用户体验，需要立即关闭广告显示。为了实现这样的操作，必须在服务器端进行控制。

而且，仅需更改服务器端的主数据，就能够设置诸如限时活动等。具体例子是，如上所述的秘密相册应用中，当满足条件时，可以下载新的显示主题！这种活动的控制可以在服务器上的yaml文件中指定。通过更改存放在服务器上的主数据，也可以实时调整游戏的难度和完成条件等。

能够在实时中调整这些设置，在需要通过审查的iOS开发中尤其有很大的优势。

3. 可以获取应用程序的日志。

如果能够了解应用程序的使用方式，便能够为用户提供更好的体验。例如，如果知道用户在教程的哪个部分跳过了，可能有可能大幅提高应用程序的渗透率。

此外，用户在使用某项功能时访问该功能的路径也是一个重要的指标。由于移动应用的屏幕并不很大，因此需要不断做出如何取舍的决策。在做出这些决策时，用户的行为是非常重要的参考材料。

即使卸载应用程序，也可以保留状态。

通过在服务器端存储用户信息，即使用户不小心卸载了应用程序，也能够恢复用户数据。

举个例子，如果在iOS中，即使不实现用户注册等功能，只需结合UUID的生成和Keychain Services，就可以在每个设备上以唯一方式管理用户。

请参考以下链接: http://xoyip.hatenablog.com/entry/2014/06/13/200000

如果按照上面所述的，通过每个终端独特地管理用户，例如在通信功能中对恶意行为的用户采取账号停用等措施也会变得有效。如果在应用程序安装时采用生成UUID的方式，即使执行了账号停用等操作，用户仍然可以卸载应用程序然后立即再次使用，这样就会被滥用。

5. 可以建立用户之间的通信功能。

经营应用程序和游戏时，希望有用户之间的互动功能是很常见的情况，我们也想要把游戏变得更具社交性。

关于这种社交功能，我认为很多开发者也想尝试引入，因为引入后持续率会有惊人的改变。但是这些功能必须在服务器端进行处理才能实现。

利用云服务(MBaaS)来实现服务器端

世界的进步令人惊叹，实际上，根据上述的描述，几乎所有这些功能都可以在不编写服务器端代码的情况下通过使用现有的云服务来实现。

据说用这个词来总称这样的服务叫做MBaaS（移动后端作为服务）。使用MBaaS的优点/缺点大致如下。

MBaaS的优点:
– 只需创建账户并在应用中导入SDK，即可轻松地引入服务器处理功能。
– 在一定规模的访问量下，通常可以免费使用。

MBaaS的缺点:
– 免费版通常功能受限。
– 如果按量计费，当应用大受欢迎时，可能需要支付相当多的费用。

以下是几个介绍方便的MBaaS的例子。

分析

使用Parse能够在不写任何服务器端代码的情况下，准备推送通知和服务器端数据库。而且，它是一个令人惊喜的服务，不需要考虑负载处理，它会自动扩展。

只需编写应用程序代码，就可以在Parse上操作预先准备好的数据库，无需编写任何服务器端代码，就可以实现包括社交功能在内的各种功能。

使用Parse可实现1.推送通知、4.保存应用程序状态、5.用户间的通信功能等。

参考：个人手机应用开发者使用Parse的15个理由。

另外，您还可以将Channel（类似于标签）与设备绑定，通过指定Channel来发送推送通知也非常方便。利用这个机制，例如，您可以只向完成教程的用户发送推送通知，或者只向通关游戏的用户发送新应用的通知，等等。

参考资料：使用Parse.com向iOS设备发送推送通知[目标定向部分]

能够看到推送通知的开启率真的非常方便。在我自己运营的个人应用中，我全部都是通过Parse来管理推送通知的。

解析的缺点
尽管目前情况可能有所改善，但在2014年，从管理界面查看和操作保存的数据非常不便。例如，无法批量更改特定条件的数据，也无法通过管理界面发出查询并查看数据等。

如果想要对用户数据进行详细分析，或者想要批量处理数据的话，我觉得最好是自己准备并使用关系数据库（RDB）。

请简化一下以下英文短语为中文：Dropbox

“嗯，用Dropbox开发应用程序？虽然感觉有点奇怪，但对于个人开发或者小规模的项目来说，实际上还是很好用的。虽然不太被人们所知，但是Dropbox将文件放在Public文件夹中会自动附加URL，就像上传到服务器的文件一样，可以从任何地方访问。”

简言之，只需将想要调整的设置以JSON格式编写并放置在Dropbox的public文件夹中，我们就能实现前面提到的实时调整应用程序的细节。

参考：使用Dropbox作为电子邮件和网站的文件托管平台。

如果要手动操作JSON的话确实很麻烦，但是可以通过使用如下所介绍的编辑软件来轻松地进行操作。

为了更好地使用JSON，以下是您需要了解的8个JSON编辑器选项。

只需在这个编辑器中编写设置的JSON，然后将文件扔到Dropbox的公共目录中，然后从应用程序中访问该URL，非常方便。

Dropbox的缺点
首先，由于Dropbox的用途与其开发方的意图并不一致，所以在规模较大的项目中最好不要使用。正如下面官方帮助文档中所提到的，一旦超过一定容量/下载次数限制，使用可能会受到限制。

请参考此链接：https://www.dropbox.com/help/4204

如果你开发的应用能够被广泛使用，那么有可能轻松地超过100,000次下载，所以最好考虑其他方法。

谷歌分析

通过使用Google Analytics，您可以了解应用程序的使用情况，包括能够获取应用程序的日志。

比如说，应用程序的连续使用天数是运营应用程序时最重要的指标，但是自己制作一个能够查看此数据的仪表板将是一个很大的麻烦。而通过使用Google Analytics，只需进行以下设置，就能方便地查看这些数据。
【Google Analytics入门】使用分段到检查应用程序的连续使用率的方法。

通过正确设置Action和Label，可以获取到已经突破教程，并成功通关至XXX阶段等信息。现在可能有更方便的方法，但之前在运营应用时，我们通过将安装日期作为Category，来分析每天的教程突破率等内容。

事件追踪 – iOS SDK

为了测量新功能的效果，检查教程改进的情况，建议分析在特定日期安装的用户行为。这被称为队列分析，最近Google Analytics还为此功能提供了官方的分析工具。

我用Google Analytics的同期分析进行了分析。

另外，最近似乎还支持了AB测试。

参考：
在iOS应用中，使用Google Analytics的AB测试功能第一部分
在iOS应用中，使用Google Analytics的AB测试功能第二部分

谷歌分析的缺点是，当试图进行涉及多个条件的分析时，会变得非常繁琐。例如，当初次使用功能A时，想知道用户在之前采取了什么行动的趋势，虽然可能可以通过巧妙处理来进行汇总，但使用谷歌分析会感到困难。

Firebase – 火力基地

其实我还没有使用过Firebase，它是一种用于实现实时数据同步的移动后端即服务（MBaaS）。它能提供类似于创建用户间通信功能的功能，并且具有实时性，比如可以用来创建聊天功能等。如果想要实现实时通信或者轮询的处理，从头开始开发相当困难，所以如果打算开发这类应用的话，考虑使用Firebase应该是一个不错的选择。

在国内有一个著名的案例，据说Wantedly先生的Sync应用程序也已经引入了，并且商业产品的使用也正在逐渐增加。

参考： iOS平台消息应用Sync开发的幕后故事
尝试使用Firebase

利用自己的服务器来实现服务器端。

虽然使用MBaaS非常有效，但如前所述，每个服务都存在一些缺点。而且如果假设有一定的访问量，则可能会意外地花费一些钱。对于企业来说，也许还可以支付一笔较大的费用，但对于个人而言，这可能很困难，但时间是有的。在这种情况下，我认为考虑自行准备服务器也是一种选择。我认为自行准备服务器的优点/缺点可以大致如下所述。

為自己準備服务器的好处:
– 可以灵活地创建一些MBaaS不支持的功能
– （如果成功创建）当面临大量访问时，相比MBaaS的成本更低

自己準備服务器的不利之处：
– 如果没有编写过服务器端代码，学习成本会相当大
– 万一面临大量访问，若服务器无法进行扩展，无法返回响应，有可能会陷入困境

从现在开始，我将总结我在自己运营的服务中准备服务器所获取的经验和见解。当然，由于篇幅限制，我无法在此处包括环境设置和语言解释的内容，因此这些只是一些实际经验和有用的技巧。

VPS与AWS的比较

就目前而言，我认为如果要独立准备服务器，大概只有两个选择。使用AWS的好处是能够自动化基础设施处理，并且提供了支持自动缩放的数据存储解决方案，例如DynamoDB和Amazon RDS for Aurora等。然而，从成本角度来看，使用VPS肯定会更便宜。

参考：【选择VPS、AWS还是Heroku】最终，我们采用了搭配樱花VPS+独角兽+Rails+Capistrano的方案【附带建设脚本】。

如果个人制作的应用程序在需要自动扩展的程度上有大量访问，那可能超出了个人开发应用程序的范畴，我觉得樱花VPS在性价比方面是最好的！仅需每月635日元即可使用。
http://vps.sakura.ad.jp/specification/

以下是关于樱花VPS的设置方面的非常有参考价值的资料。
樱花VPS＆AWS＆VULTR EC2／CentOS 6.5的Rails服务器构建步骤！【Ruby】

服务器端开发语言/框架

可以用于进行服务器端开发的语言有很多种，比如PHP、Ruby、Python和Java。而且每种语言还有各种不同的框架，所以最后大家往往会纠结于哪个更好。总的来说，嗯，我认为任何一种都可以。根据个人喜好来选择吧！

所以，對於像是說”不過”這樣的人，我個人推薦的是使用ruby + sinatra的組合。它的好處在於，它只擁有最基本的功能，所以需要記住的東西非常少。如果按照以下的教程實施，如果你使用的是Mac，我認為你可以在大約3分鐘內在瀏覽器上顯示出Hello World。【初心者向け】RubyとSinatra、アンテナサイトの作り方

如果有使用过Rails的人来说，功能方面当然更加充实，所以我认为Rails更加适合。对于我自己来说，如果我需要开发一个新的应用程序并且需要服务器端实现，我会考虑使用Rails。

然而，在从零开始创建最基本的运动物体方面，我认为Sinatra是一个相当好的选择。

暂存环境

「ステージング環境」是指一个与正式环境几乎相同的服务器环境，可以进行功能测试。在应用程序开发和服务器端开发上的一个区别是，如果正式环境机器的代码发生更改，这将立即影响到用户手中的应用程序的操作。

因此，如果要正常进行开发，建议您租用另一台价格为635日元的さくらVPS计划，并创建一个临时的staging环境。

在只有生产环境的情况下运营应用程序，即使更改设置或更改源代码，也需要花费成本来确认其是否正常工作。最糟糕的情况是，如果直接触碰生产配置文件，可能导致所有用户的应用程序无法运行。

部署

部署意味着将开发完成并在暂存环境中确认运行的代码投入到生产环境中。如果认真创建环境，则最好使用自动化工具如Capistrano，但是如果只是个人应用，可能不想花太多成本，那么也可以直接通过ssh连接到生产机器并进行git pull。虽然可能会招致专业的运维人员的责备，但是我个人会编写一个简单的部署脚本，通过ssh连接从暂存服务器上部署到生产环境中。

echo "cd /var/www/xxxxxxx;
      git pull --rebase;
      export RACK_ENV=production
      bundle install --path vendor/bundler;
      bundle exec rake db:migrate
      touch tmp/restart.txt;" | ssh username@host -i  key_path

现金策略（客户部分）

在个人开发应用的情况下，我认为大多数人会怀着不想花太多钱的想法进行开发。虽然不想花钱，但大家都希望这个应用能大受欢迎！如果真的大受欢迎的话，问题就来了，那就是负荷。负荷。即使作为应用工程师工作，也会在公司听到服务器团队的桌子上传来“负荷太大…”这样的声音。

为了承担负荷，可以利用金钱的力量有很多选择，但如果决定不花费金钱，就需要采取一些切实的应对措施。作为解决策略之一，有效的方法是尽可能减少对服务器的访问。归根结底，如果没有访问，就没有负荷！

所以，在获取所需数据之后，最好将数据保存在客户端一段时间，以防万一（如果没有金钱的话）。例如，

不整合に備えてアプリ側の設定画面に、キャッシュ削除ボタンを用意しておく

可以考虑各种实施方式。

缓存策略（服务器部分）

大概在服务器端应用大受欢迎时，最困难的是对数据库的写入处理。或者说，如果需要进行分散处理，那肯定已经不是个人应用的级别了，超出了本文的范畴。

然而，对于除此之外的数据加载，可以在不花费太多成本的情况下减轻负载。例如，数据的加载可以通过从服务器内存中返回缓存数据而不是直接从数据库读取信息来快速访问。

Redis和Memcache等中间件可以简单地实现这样的机制。由于Memcache具有简单的接口，因此更容易上手，但Redis可以更容易地操作数据集合（支持排序等功能），所以如果不确定可以先仅使用Redis，也可以。在我自己运营的应用中最初只使用了Memcache，但最终由于需要排序等功能，不得不同时使用Redis和Memcache。

Redis使用指南
memcached基本操作

健康检查

如果你使用的是个人运营的应用程序，即使出现故障，也不会有负责人打电话给你，所以遗憾的是你需要自己察觉到故障。

制作一个复杂的系统并不必要，只需每分钟访问一次网站，并确认通过HTTP状态码返回200OK。如果返回的不是200，则发送电子邮件。创建这样的机制可以防止应用程序无法正常运行而不自知的情况发生。

参考：简单的脚本和定时任务用于网站健康检查和Apache重启。

有一次，我使用的放置运营应用程序的服务器由于樱花VPS的配置更改而被强制重新启动，导致应用程序崩溃，并收到了HealthCheck的电子邮件提醒，我才意识到这个问题。

使用Amazon S3进行数据库数据备份

雖然是個人經營的應用程式，建議還是至少要備份一下資料庫。在這方面，Amazon S3非常方便。

在我自己的情况下，我创建了以下简易脚本，每天将MySQL的dump备份上传至S3，并保留最多一周的数据。（我不记得为什么只保存一周的数据，但我想可能是因为我不想支付太多费用）

使用 fluentd 进行日志分析

我还对樱花进行了额外的付款，并准备了一个用于日志的服务器，使用fluentd将用户的所有操作都发送到日志服务器。

我认为在分析收集到的日志时有很多方法可供选择，但由于存在许多优秀的软件如awk、grep、sort和wc，基本上我们使用它们来进行数据分析。坦率地说，现在我后悔没有同时使用BigQuery等工具，但即便如此，我们仍然能够以非常细致的粒度分析用户的行为，所以还算不错，我想。

虽然最后没有实现到那一步，但是可以将nginx和apache的日志也集中到fluentd中，这样就可以在一个环境中集中管理日志数据并发出查询，这应该是非常方便的。（尽管在个人应用程序中可能无法做到这一点）

在实时日志利用方面，使用Fluentd作为参考点。

总结

最后，根据每种情况做一个总结，我认为如下所示！

・既存のアプリを使う
・自分でアプリを作る時間も金もないが、もし大ヒットしたら金を支払う
・時間はあるが金はないので、VPSを使用して自分のサーバー環境を作ります。アプリが成功しても問題ありませんが、適切な設計が必要です
・金はあるが時間がないので、優れたサーバーサイドエンジニアを雇えばいいですね。

虽然时间和金钱都匮乏，但要开发一个即使大受欢迎也能承受负荷的应用程序，如何做？

很遗憾，我们没有银弹。但是，如果有的话，也许值得好好思考一下能创造财富的应用商业模式吧。

不管怎么说，我认为重要的还是将应用的价值传达给用户，如果考虑到应用能够大热的话，就要认真思考商业模式。相反地，如果无法筹集足够的资金来支付MBaaS的费用以及雇用工程师来应对高负荷，那么就必须设法解决应用的商业模式问题，否则情况将无可挽回。

以上是我在独自进行应用程序开发并搭建服务器端所获得的经验！