演员与HTTP
如果使用参与者和使用HTTP端点之间的交流之间有很大区别，我真的不会明白。
在线文档一直在说“演员接收消息并可以改变状态”……嗯，HTTP端点功能也是如此。
HTTP可以调用异步函数，因此演员可以同步并且异步不会使它们与众不同。
哦，如果区别在于，演员可以自我康复，或者某些演员可以创建或杀死其他参与者，那么……使用与HTTP的技术，例如反向代理和/或Kubernetes解决相同的问题。
我想念什么？什么区别参与者与仅使用HTTP协议，端点和反向代理区分开来？
我敢肯定，这个问题的答案不仅有助于我的困惑，而且将来有相同混乱的人的困惑。
I don’t really get if there is much of a difference between using actors and using HTTP endpoints for communication between processesses.
Documents online say all the time “actors receive messages and can change state”… well, so do HTTP endpoint functions.
HTTP can call async functions, so the fact that actors can be sync and async does not set them apart.
Oh, and if the difference is that actors can be self healing, or that some actors can create or kill other actors, well… using tech with http such as reverse proxies and/or kubernetes solve the same issues.
What am I missing? What differentiates actors from simply using the HTTP protocol, endpoints, and reverse proxies?
I am sure an answer to this question will not only help my confusion, but also that of a person with the same confusion in the future.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
您似乎正在混淆一些问题。
为什么Akka有自己的RPC而不是HTTP。
答案是路由/可靠性。 Akka的目的是分布式分布式系统，当您进行RAW HTTP时，如何使所有消息保持正确的所有路线？另外，使用大量机器，您如何确保每次通话一次一次，仅在群集上一次发生一次？
为什么要与演员打扰？
演员是高度并发系统的模式。演员允许开发人员推理状态寿命和流程居住的地方，将它们分开，并允许演员运行时快速运行大量演员实例，而不必担心复杂的事物，例如“线程”和“线程安全”。
当您到达职业生涯的某个点时，您会发现“线程安全”非常难以正确。哎呀，我最喜欢的编程语言是一种以迫使您正确进行线程而闻名的语言。问题在于，如果没有一些系统的过程来编写代码，那么在完全不同的项目中，两个看似无关的代码行可能会产生难以复制的细微错误。
高度并发系统的另一个范式是功能性编程，但是与其相关的绩效惩罚。
TLDR
Actors模式旨在解决您在大型庞大的代码库中遇到的问题，许多非天然级别的开发人员同时使用数百台服务器运行。
You seem to be conflating a few issues.
Why does Akka have its own RPC instead of HTTP.
The answer is routing/reliability. Akka is meant to hugely distributed systems, and when you do raw HTTP, how do you keep all the routes correct for each message? Also, with huge numbers of machines, how do you ensure each call happens once and only once on your cluster?
Why bother with Actors?
Actors are a pattern for highly concurrent systems. Actors allow developers to reason where state lives and where processes live, separate them out, and allow the actor runtime to quickly run huge numbers of actor instances without worrying about complex things like "threads" and "thread-safety".
When you get to a certain point in your career, you will find that "thread-safety" is incredibly hard to do right. Heck, my favourite programming language is one that is famous for forcing you to do threading correctly. The problem is that, without some systematic process to write your code, two seemingly unrelated lines of code in completely different projects can produce subtle bugs that are hard to reproduce.
Another paradigm for highly concurrent systems is Functional Programming, that however has massive performance penalties associated with it.
TLDR
The Actors pattern is designed to solve problems you encounter in large sprawling codebases with many non-genius level developers working on it at the same time, running on hundreds of servers.
演员具有名为“透明区域”的良好属性，即发送消息时，您不在乎接收者是本地还是遥控器。当本地化时，消息传递非常便宜（即至少在C ++ Actor Systems中，您可以每秒传递数百万消息），但是对于网络消息（可以是http（s））数量通过（数十）数量来衡量。
因此，令人不愉快的结果是，您可以相对轻松地从单个节点网络群集中从单个节点缩放应用程序，或者您可以通过网络上的本地节点从本地节点上卸载一些流量。因此，演员在缩放时为您提供一些的建筑灵活性。没有参与者，您在本地处理的请求/数据和远程处理之间就有一个非常严格的边界，而它们之间的移动通常是非平凡的任务，甚至可能影响架构。
Actors have nice property named "transparent locality", i.e. when you send a message, you don't care whether the receiver is local or remote. When it is local, the message delivery is quite cheap (i.e. you can deliver millions of messages per second at least in C++ actor systems), but for network messages (it can be http(s)) the amount is measured by (tens of) thousands.
So, the nice consequence, that you can relatively easily scale your app from single node over network cluster of nodes, or, you can offload some traffic from local node over network. So, actors, gives you some architectural flexibility in scaling. Without actors, you have a very strict border between locally processed requests/data and remotely processed, and moving between them is usually non-trivial task, might even affect architecture.