Fatal编程技术网
  • erlang/
  • 考虑将应用程序从.NET移植到Erlang-需要建议吗

考虑将应用程序从.NET移植到Erlang-需要建议吗

erlang

考虑将应用程序从.NET移植到Erlang-需要建议吗,erlang,application-lifecycle,Erlang,Application Lifecycle,我正在寻找Erlang未来版本的分布式软实时托管基于web的电话应用程序（即Erlang看起来绝对是此类应用程序的完美选择）。我来自.NET的背景，这个应用程序的当前版本使用C#、WCF和JQuery的组合来提供服务。我现在需要Erlang来让我的上线时间增加9秒，并让我的服务器费用得到更多的回报 之前，我在这里设置了一个开发过程，将VS.NET、GIT、TeamCity和MSI文件的自动部署结合到我们维护的各种环境中。这并不完美，但我们现在都很满意。我想知道，像我们这样的流程是否适用于这种完全

我正在寻找Erlang未来版本的分布式软实时托管基于web的电话应用程序（即Erlang看起来绝对是此类应用程序的完美选择）。我来自.NET的背景，这个应用程序的当前版本使用C#、WCF和JQuery的组合来提供服务。我现在需要Erlang来让我的上线时间增加9秒，并让我的服务器费用得到更多的回报

之前，我在这里设置了一个开发过程，将VS.NET、GIT、TeamCity和MSI文件的自动部署结合到我们维护的各种环境中。这并不完美，但我们现在都很满意。我想知道，像我们这样的流程是否适用于这种完全不同的技术堆栈（莱姆）

我相信我们以前用.NET解决的所有编程难题都可以用更少的代码用Erlang更好地解决，所以我完全相信语言的选择。阅读有关Erlang的实用书籍和O'Reilly书籍时，我还不了解我应该如何调整我的软件工程和应用程序生命周期管理（ALM）流程以适应新平台。我看到，就地代码更新可以使我（以及我的测试和操作团队）的生活变得更加轻松（与试图在windows网络上部署MSI文件的痛苦相比），但我不确定在使用Erlang时应该如何改变

您将如何：

  • 在Erlang中进行连续集成（是否常用？）
  • 在QA周期中使用它（我们经常使用GIT运行并发主题分支，这些分支有自己的小QA周期，所以它们都部署到测试环境中）
  • 构建代码并将其分发到开发、测试、UAT、登台和产品环境
  • 将代码生成阶段集成到构建周期中（我们目前使用MSBUILD+T4模板）
  • 为一组不同的服务器集中日志记录（我们目前使用Log4Net、MSMQ等）
  • 使用SCOM等工具执行警报
  • 确定是否有人/物错误配置了您的生产服务器
  • 只有在充分的QA（仅由授权人员）之后才允许生产热修复
  • 配置应用程序的性能（计算和通信）
  • 与基于windows的active directory服务器交互
我想我需要知道什么对你有用，为什么！您使用了哪些工具和框架？你尝试了什么失败了？如果你能重新开始，知道你现在知道了什么，你会有什么不同吗？

哇，好长的帖子。首先，你应该意识到99.9%和更好的kool-aid在失明时饮用有点危险。是的，您可以得到一些惊人的稳定性数据，但是您需要以一种促进这一点的方式编写程序。它不是免费的。这也不是魔法造成的。应用程序的设计必须确保其他子系统能够恢复。OTP会给你很多帮助，但是学习还是需要时间的

持续集成：易于实现。如果您可以通过构建bot调用
rebar
或
make
，您可能已经在这里设置好了。查看eunit、cover和Erlang QuickCheck（迷你版对初学者来说是免费的）-所有这些都可以从钢筋上运行

QA周期：我在这里没有任何问题。同样，如果使用
rebar
可以构建最小化erlang vm的嵌入式版本，您可以在任何地方复制并运行（它们是自包含的）。通过稍微改变代码路径，您甚至可以非常轻松地将修补程序热部署到这样一个系统中，这样您就有了一个更新修补程序的覆盖层。你有很多选择。Git已经帮了你很多

环保：很容易做到

日志集中：查看SASL和错误日志记录器。你可以在这里做任何你想做的事

警报：系统可以根据您的需要进行探测（Erlang中的内省功能很强）。但是，您可能需要编写一些代码来将其连接到您选择的系统

配置错误：配置文件是Erlang术语。如果可以计算，就可以完成

安全性：限制访问权限。在我看来，这是人的问题，不是技术问题

配置：cprof、cover、eprof、fprof、instrument+两个分布式系统，用于执行相同的操作。随机抽样也很容易（Erlang中的内省很强）

Windows交互：不知道。（偏见：我上次专业使用windows是在1998年左右）

一些个人观察：

您最大的问题可能是您试图将Erlang塞进您现有的进程，而它可能会抵制。这是一个新的环境，因此在某些地方需要新的方法，您应该期望能够适应并解决您在过程中发现的限制。普遍的共识是它可以工作（它在几个大网站上工作）

看起来你有一个完善而严格的流程。为了让位于一种新的思维方式，这一过程被允许牺牲多少

你的程序员愿意抛弃几乎所有的OO知识吗？否则，你将以一个社会问题而不是技术问题结束。然而，如果他们像我一样，他们会欢呼，拍手，并通过使用一种有趣的语言以新的方式解决一个有趣的问题而获得持续的兴奋

你有多少有Erlang经验的程序员？如果你有相当少的，那么最好先在一些较小的子系统上切齿，然后朝着更大的目标努力。充分利用这一系统需要几个月甚至几年的时间。不过，几周内就可以获得部分好处。

这不是一个垃圾答案！我们根本没有经验丰富的Erlang开发者（我现在只是在学习），我们都将重新学习技能（不确定谁会鼓掌）。我个人认为OO和MS的最佳实践理念是一件简单的夹克，而不是一种增强（对于这种应用）