建造模式实际应用_建造多少，购买多少：为聊天和消息传递应用程序提供支持...-CSDN博客

建造模式实际应用

by Joe Hanson

通过乔·汉森

建造多少，购买多少：为聊天和消息传递应用程序提供支持 (How much to build and how much to buy: powering chat and messaging apps)

When you’re building a chat application of any kind — from mobile group messaging and multiplayer in-game chat, to customer support and chatbots — choosing the right platforms, frameworks, and protocols can make or break your business.

当您构建任何类型的聊天应用程序(从移动组消息传递和多人游戏中聊天，到客户支持和聊天机器人)时，选择合适的平台，框架和协议都可以决定您的业务成败。

That’s because deciding whether to build or buy a chat app isn’t binary. The days of making a decision to do-it-yourself or buy from a vendor are gone.

那是因为决定是否构建或购买聊天应用程序不是二进制的。决定自己动手或从供应商那里购买的日子已经一去不复返了。

The question now is how much do I want to build, and how much do I want to buy?

现在的问题是我要建造多少，我要购买多少？

Between open-source, IaaS, PaaS, SaaS, SDKs, APIs and Microservices, businesses have never had more options for how they want to build their chat products. And the spectrum of choices only continues to widen.

在开源，IaaS，PaaS，SaaS，SDK，API和微服务之间，企业从未想过要如何构建其聊天产品的更多选择。选择的范围只会继续扩大。

As cloud computing becomes more accessible and affordable, innovative new companies solve specific problems. Devices become more powerful. If businesses want to keep up, they must understand the vendor landscape along with the benefits and challenges of each option along the spectrum.

随着云计算变得越来越容易获得和负担得起，创新型新公司将解决特定问题。设备变得更加强大。如果企业希望跟上发展步伐，那么他们必须了解供应商的态势，以及每种选择的收益和挑战。

As a result, there are many mistakes that developers and organizations can make when choosing chat or messaging platforms for their application.

结果，在为应用程序选择聊天或消息传递平台时，开发人员和组织可能会犯许多错误。

In this post, we’ll discuss a number of different chat application types and look at the different platform options for powering and delivering messaging apps. We’ll also discuss challenges that can arise from making certain decisions throughout the development cycle, like scalability, time to market, and other differentiators.

在本文中，我们将讨论许多不同的聊天应用程序类型，并探讨用于驱动和交付消息传递应用程序的不同平台选项。我们还将讨论在整个开发周期中做出某些决定(例如可伸缩性，上市时间和其他差异化因素)可能带来的挑战。

选择聊天服务提供商：当前形势 (Choosing a chat service provider: current landscape)

There are a wide variety of options across the build vs. buy spectrum. You have open-source on one end (build) and fully built out (SaaS) solutions on the other (buy). With hundreds of options in between, all with different pros and cons, we’ll seek to give you an idea of the landscape in a simple chart:

在构建和购买范围内有多种选择。您在一端拥有开放源代码(构建)，而在另一端拥有完全内置的(SaaS)解决方案(购买)。两者之间有数百种选择，各有优缺点，我们将尝试通过简单的图表向您介绍一下情况：

开源协议 (Open-source protocols)

The furthest on the build side are open-source protocols like WebSockets and HTTP Long Polling. These are simply protocols, which means that you manage everything to make them work. That includes spinning up your back-end infrastructure, maintaining it, building new SDKs to support new devices and languages, and everything else.

在构建方面最远的是诸如WebSockets和HTTP Long Polling之类的开源协议。这些只是简单的协议，这意味着您可以管理一切以使其正常工作。这包括扩展后端基础架构，对其进行维护，构建新的SDK以支持新的设备和语言以及其他所有功能。

These are great for prototyping, building small applications, or getting your hands dirty with the full stack. But most real-time messaging services offer free versions with all the back-end infrastructure included. And you’ll need to gear up for some serious headaches when it’s time to scale.

这些非常适合用于原型设计，构建小型应用程序或使整个堆栈变脏。但是大多数实时消息服务都提供了包括所有后端基础架构的免费版本。当您需要扩展时，您需要为一些严重的头痛做好准备。

开源框架 (Open-source frameworks)

Open-source frameworks are a smidge past pure build, but still require you to maintain the infrastructure on your own. For chat use cases, open-source frameworks tend to rely on a community of developers to update the framework and maintain the client SDKs.

开源框架是过去纯构建的产物，但仍然需要您自己维护基础结构。对于聊天用例，开放源代码框架倾向于依赖开发人员社区来更新框架并维护客户端SDK。

基础架构即服务(IaaS) (Infrastructure-as-a-Service (IaaS))

These are the big dogs — the cloud infrastructure service providers like AWS, Digital Ocean, Azure, Bluemix, and Google Cloud. They actually end up powering a lot of the PaaS, messaging solution providers, and SaaS products that we’ll talk about next.

这些都是大狗-云基础设施服务提供商，例如AWS，Digital Ocean，Azure，Bluemix和Google Cloud。实际上，它们最终为许多PaaS，消息传递解决方案提供商和SaaS产品提供了支持，我们将在下面讨论。

In a nutshell, you can use open-source protocols with an IaaS to launch your app. The infrastructure is taken care of, but there’s still a lot of building to do yourself.

简而言之，您可以将开源协议与IaaS结合使用来启动您的应用程序。基础设施得到了照顾，但仍有许多工作要做。

平台即服务(PaaS) (Platform-as-a-Service (PaaS))

PaaS providers like PubNub and Firebase offer hosted solutions for building chat applications. They include not only the infrastructure, but also the APIs for building chat features. Building and customizing the application requires engineering resources, since their SDKs are open. But security and maintenance of the service (the back-end and the client SDKs) are handled by the PaaS.

PaaS提供商(例如PubNub和Firebase)提供用于构建聊天应用程序的托管解决方案。它们不仅包括基础结构，还包括用于构建聊天功能的API。由于其SDK是开放的，因此构建和自定义应用程序需要工程资源。但是服务(后端和客户端SDK)的安全性和维护是由PaaS处理的。

聊天框架 (Chat frameworks)

These framework providers are almost as close to buying as you can get, but still require a fair amount of engineering. The big difference between these providers and PaaS is that they provide more of a black box approach — you have less freedom to customize the APIs and infrastructure. Often they’ll provide the UI as well.

这些框架提供者几乎尽力而为，但是仍然需要大量的工程设计。这些提供程序和PaaS之间的最大区别是，它们提供了更多的黑盒方法-您自定义API和基础结构的自由较少。通常，他们也会提供UI。

PubNub ChatEngine offers a more open and extensible framework, for example. Layer would fall closer to the black box SaaS chat solutions, but still offers a fair amount of customization options.

例如，PubNub ChatEngine提供了一个更开放和可扩展的框架。 Layer将更接近黑盒SaaS聊天解决方案，但仍提供了大量定制选项。

SaaS (SaaS)

Lastly, the furthest over on the buy side of the spectrum, SaaS companies provide a fully-built out solution that requires a small amount of engineering. UI, integrations, and infrastructure are all handled by the SaaS provider. Leaders in the space include Intercom and Zendesk Chat.

最后，SaaS公司是购买范围中最遥远的一员，提供了需要少量工程设计的完整解决方案。 UI，集成和基础架构均由SaaS提供程序处理。该领域的领导者包括对讲和Zendesk Chat 。

选择聊天服务提供商时要问自己的问题 (Questions to ask yourself when choosing your chat service provider)

As with all the other parts of your critical infrastructure, the key questions still remain the same:

与关键基础架构的所有其他部分一样，关键问题仍然保持不变：

Do you run your own service, or do you utilize a hosted service?
您是运行自己的服务，还是使用托管服务？
How much does it cost upfront? How much will it eventually cost at scale?
前期要花多少钱？最终它将在规模上花费多少？
Is the hosted service reliable, secure, and scalable?
托管服务是否可靠，安全且可扩展？
How mission-critical is chat to your application?
与您的应用程序聊天对任务至关重要吗？
Who on your team will maintain it? Do they have the skills to make it scalable and secure?
您团队中的谁会维护它？他们是否具有使其可扩展和安全的技能？
Where does the service store the data, and who has access to it?
服务在哪里存储数据，谁可以访问？

选择您的聊天服务提供商：开源与托管 (Choosing your chat service provider: open-source vs. hosted)

When it comes to software development, everyone knows that what works in the lab is not guaranteed to work in the wild. That’s because the wild presents all those challenges you may not think about, or may not even know about yet.

在软件开发方面，每个人都知道不能保证在实验室中可以正常使用。那是因为野性带来了您可能没有想到，甚至可能还不知道的所有挑战。

When it comes to choosing the right technology to power your chat, there are a number of build and buy considerations to look at. We’ll look at security, scalability, reliability, customization, and business reasons for selecting your stack in the lab vs. the real world.

在选择合适的技术来推动聊天时，需要考虑许多构建和购买方面的注意事项。我们将研究在实验室和实际环境中选择堆栈的安全性，可伸缩性，可靠性，自定义性和业务原因。

基础设施 (Infrastructure)

In you’re going down the open-source route, you’ll choose your tool, install it, and orchestrate the operation of that tool.

在遵循开放源代码路线的过程中，您将选择工具，安装工具并协调该工具的操作。

From there, you’ll start thinking about the infrastructure side of things, like load-balancing and redundant nodes. These are requirements for launching an app at scale. This is when you may tap an IaaS provider to handle the back-end. Even so, it will still require heavy engineering, including:

从那里开始，您将开始考虑诸如负载平衡和冗余节点之类的基础结构方面。这些是大规模启动应用程序的要求。这是您可以点击IaaS提供程序来处理后端的时候。即使这样，仍然需要大量工程，包括：

Spinning up multiple testing, staging, and production environments
启动多个测试，登台和生产环境
Twelve factor
十二因素
Coordinating provisioning for those multiple environments (like a Kubernetes)
协调针对多个环境(例如Kubernetes)的资源调配
Deploying your application code to the environments
将应用程序代码部署到环境中
Setting up service management, system monitoring, and Ops alerting
设置服务管理，系统监视和操作警报
Creating a load balancing scheme (like Nginx or HAProxy)
创建一个负载平衡方案(如Nginx或HAProxy)
Figuring out how to segment data by channels or topics (like Redis pub/sub with Socket.io)
弄清楚如何按渠道或主题细分数据(例如使用Socket.io的 Redis pub / sub )
Finding a store and forward solution for signal recovery, like in-memory caching
寻找用于信号恢复的存储转发解决方案，例如内存中缓存
Implementing a method to detect which client to connect to which data center and port
实现一种方法来检测哪个客户端连接到哪个数据中心和端口
Figuring out which channels/topics to send/receive for a given client
找出要发送/接收给定客户的频道/主题
Deciding which platforms and languages you’ll support
确定要支持的平台和语言
Creating universal data serialization (JSON)
创建通用数据序列化(JSON)
Customizing code to detect data uplink that works across device types
定制代码以检测跨设备类型工作的数据上行链路
Determining Quality of Service and level of loss, and developing a data recovery scheme (or settle for “fire and forget”)
确定服务质量和丢失程度，并制定数据恢复方案(或为“一劳永逸”而努力)
Deciding which APIs and capabilities you’ll need, then building them (presence detection)
确定所需的API和功能，然后构建它们(状态检测)

That’s a laundry list of considerations. But if you’re choosing the open-source route, these are the things you’ll have to consider once you’re outside the lab and scaling your app.

那是考虑的清单。但是，如果您选择开放源代码路线，那么一旦您不在实验室并扩展应用程序，就必须考虑这些因素。

安全 (Security)

For chat, security is paramount. We’re increasingly sending more confidential and mission-critical information via chat applications, from financial details to chatbot commands. Ensuring that you have full control over access and encryption is imperative.

对于聊天，安全至关重要。我们越来越多地通过聊天应用程序发送更多的机密和关键任务信息，从财务详细信息到聊天机器人命令。必须确保您完全控制访问和加密。

Every successful chat service provider offers different levels of security. Here are the most important features that must be included in any hosted-service provider:

每个成功的聊天服务提供商都提供不同级别的安全性。以下是任何托管服务提供商中必须包含的最重要的功能：

End-to-end encryption with TLS for in/outbound packets and AES for packets
使用TLS进行入/出数据包和AES进行数据包的端到端加密
Support fine-grained, token-based access control. Token-based access control allows you to grant and revoke access to any messaging channel.
支持基于令牌的细粒度访问控制。基于令牌的访问控制使您可以授予和撤消对任何消息通道的访问。
Compliance is key, especially for verticalized chat applications. The hosted-service provider should be certified for HIPAA (healthcare), SOC 2, GDPR (EU), Data Shield, and SafeHarbor (EU/US).
合规性是关键，尤其是对于垂直聊天应用程序而言。托管服务提供商应获得HIPAA(医疗保健)，SOC 2，GDPR(欧盟)，Data Shield和SafeHarbor(欧盟/美国)的认证。

For those who choose not to utilize a hosted-service provider, the following are additional security considerations that you’ll have to handle on your own:

对于那些选择不使用托管服务提供商的用户，以下是您必须自己处理的其他安全注意事项：

Purchasing a TLS certificate, then distributing and managing that certificate securely
购买TLS证书，然后安全地分发和管理该证书
Figuring out how to protect channels and topics (not covered by TLS)
弄清楚如何保护频道和主题(TLS未涵盖)
Building an authorization systems for users
为用户建立授权系统
Considering AES and/or RSA encryption for payloads (not covered by TLS)
考虑有效负载的AES和/或RSA加密(TLS并未涵盖)
Complying with legislative security policies (like SafeHarbor or HIPAA)
遵守法律安全政策(例如SafeHarbor或HIPAA)

可扩展性 (Scalability)

For chat apps with thousands of active users chatting simultaneously, and ones that continue to grow, expertise on scale is a major challenge. Both open-source and some hosted-service providers deal with this. But when it comes to scale, hosted solutions mitigate the risk of app-breaking scalability issues far greater than open-source options.

对于具有成千上万的活跃用户同时聊天并且持续增长的聊天应用程序，大规模的专业知识是一个重大挑战。开源和某些托管服务提供商都对此进行了处理。但是，就规模而言，托管解决方案所带来的应用破坏性可扩展性问题的风险要远大于开源选项。

For hosted solutions, there are a couple indicators that your service of choice will scale with your app growth.

对于托管解决方案，有两个指标表明您选择的服务将随着应用程序的增长而扩展。

Multiple global points of presence: Chat messages should be globally replicated, so that if messages are dropped, a backup message will be delivered. This also increases the performance of your application, as every chat user doesn’t have to connect to the same data center (especially those halfway across the earth).

多个全球存在点：应当全局复制聊天消息，以便在删除消息时将传递备用消息。由于每个聊天用户都不必连接到相同的数据中心(尤其是在地球中间的数据中心)，因此这也提高了应用程序的性能。

Uptime SLAs: Uptime SLAs hold hosted-service providers accountable, and they should credit you if those SLAs are not met based on the terms.

正常运行时间SLA：正常运行时间SLA使托管服务提供商负责，如果根据条款未能满足这些SLA，则他们应向您归功。

For the do-it-yourselfers, you need to consider:

对于自己动手的人，您需要考虑：

A custom built load testing service that can simulate a realistic audience
定制的负载测试服务，可以模拟现实的受众
Creating update protocol & continuously modifying your network to support new products/services
创建更新协议并不断修改您的网络以支持新产品/服务
Paying for Socket server costs, QA systems, and hot failovers
支付套接字服务器成本，质量检查系统和热故障转移
Ongoing Ops monitoring and additional headcount required
正在进行的运营监控和所需的额外人员

可靠性 (Reliability)

There is so much competition for messaging applications. With the app store a click away, any issue a user encounters can lead them to an alternative. Reliability is a key factor in making your app sticky. When vetting hosted service providers, here are a couple key indicators of reliability:

消息传递应用程序竞争如此激烈。只需单击一下应用商店，用户遇到的任何问题都可能导致他们选择其他方法。可靠性是使您的应用程序具有粘性的关键因素。审核托管服务提供商时，以下是可靠性的几个关键指标：

Data replication for multiple points of presence and automatic failover to ensure that messages are delivered 100% of the time (and actually in realtime)
用于多个存在点的数据复制和自动故障转移，以确保在100％的时间内(实际上是实时)传递消息
Message “catch-up” in case of connection dropout (if a user is in a tunnel, for example, they’ll receive the message when they come out the other side)
如果连接断开，消息“追赶”(例如，如果用户在隧道中，当他们从另一端出来时，他们会收到消息)

If using an open-source solution, you’ll have to also handle:

如果使用开源解决方案，则还必须处理：

Building a load distribution system
建立负载分配系统
Identifying error messages
识别错误消息
Building a log system
建立一个日志系统
Knowing when faults occur and developing a playbook of responses
知道何时发生故障并制定应对方案
Building service management (like PagerDuty)
建筑服务管理(如PagerDuty)
Developing multi-datacenter deployment
开发多数据中心部署

开源与托管 (Open-source vs. hosted)

When you look at the major considerations, you can see that building out a realtime messaging system on your own poses a lot of risks. It is a great option for smaller chat applications. But once you begin to grow, security, reliability, and scalability challenges can add up.

当您查看主要注意事项时，您会发现自己构建实时消息传递系统会带来很多风险。对于较小的聊天应用程序，这是一个不错的选择。但是一旦您开始成长，安全性，可靠性和可伸缩性挑战就会加起来。

Most hosted-solution providers also allow a free-forever sandbox pricing tier. This allows you to develop your app without paying, and once you’ve grown to a certain size, you pay as you grow. For those companies looking to move fast and not wanting to worry about all the intricacies of networking and infrastructure, hosted-solutions are the way to go.

大多数托管解决方案提供商还允许使用永久免费的沙盒定价层。这样一来，您无需付费即可开发应用程序，一旦规模增长到一定规模，就可以按需付费。对于那些希望快速发展而又不想担心网络和基础设施的复杂性的公司而言，托管解决方案是必经之路。

If you enjoyed this article, please give it a clap so more people see it. Thanks!

如果您喜欢这篇文章，请拍一下它，以便更多的人看到它。谢谢！

If you’re looking for a in-depth look into chat, look no further than our new eBook: Chat is More Than Hot Air — How to Build the Digital Future. In it, we cover:

如果您想深入了解聊天，请浏览我们的新电子书：聊天绝不只是热门-如何构建数字未来 。在其中，我们涵盖：

The current landscape of chat technology: the different flavors of chat, choosing the right technology from what’s available on the market today and a comparison of build vs. buy and hosted vs. open source.
聊天技术的当前前景：不同的聊天风格，从当今市场上可用的技术中选择合适的技术，并比较构建与购买，托管与开放源代码。
How chat is evolving: a view into how chat apps are changing from simple messaging to transform how industries and users communicate.
聊天如何演变：了解聊天应用程序如何从简单的消息传递转变为行业和用户的交流方式。
How to ensure you’re at the forefront of innovation: a look at what features and experiences can be delivered to set yourself apart from the rest.
如何确保您处于创新的最前沿：了解可以提供哪些功能和体验以使自己与众不同。

Originally published at www.pubnub.com.

最初在www.pubnub.com上发布。