ocr识别处理 解决方案
介绍 (Introduction)
In this article, we will show you how to create a serverless solution for implementing a scalable Optical Character Recognition (OCR) system. In a system like this, scalability is a requirement. At certain times, we can expect possible bursts of traffic into the system where we need to process all of these requests and communicate the result back to the user in a timely manner. To cater to this, we need a system that scales dynamically. One possible solution is to model the required workers and deploy them in a Kubernetes environment to achieve our scaling requirements.
在本文中，我们将向您展示如何创建无服务器解决方案来实现可伸缩的光学字符识别(OCR)系统。 在这样的系统中，可伸缩性是必需的。 在某些时候，我们可以预期到系统中可能会出现流量突发，我们需要在其中处理所有这些请求并将结果及时传达给用户。 为此，我们需要一个可以动态扩展的系统。 一种可能的解决方案是对所需的工作人员进行建模，并将其部署在Kubernetes环境中，以实现我们的扩展需求。
This approach has been implemented and discussed in this article. Here, we will implement the same solution using Azure Functions in Ballerina (referred to as Ballerinalang in the rest of the article) and show how it can be implemented with considerably fewer lines of code, which resulted in lesser complexity and better maintainability.
本文已实现并讨论了这种方法 。 在这里，我们将使用Ballerina中的 Azure函数(在本文的其余部分中称为Ballerinalang)来实现相同的解决方案，并展示如何用更少的代码行来实现它，从而减少了复杂性并提高了可维护性。
建筑 (Architecture)
Figure 1 shows the deployment diagram of the solution that we will be implementing. The user input is taken using an HTTP endpoint, where the user will be providing the binary data for the image and an email address as a query parameter. This HTTP endpoint will be implemented using an HTTP trigger in Azure Functions, and from here, using their output binding mechanism, we store the image data and the job request information in a blob storage and a queue storage respectively. The reason why we are going towards an asynchronous processing approach is that, in this manner, it is easier to scale the required processing units as needed. For example, the job submission function is not a CPU bound task, but rather it does a simple data storage operation. Whereas, the image processing function, which reads in from the blob and queue storage, will have a more expensive and time-consuming task of doing the actual OCR operations. So the serverless environment can scale the functions with its requirements.
图1显示了我们将要实现的解决方案的部署图。 使用HTTP端点获取用户输入，在HTTP端点上，用户将提供图像的二进制数据和电子邮件地址作为查询参数。 此HTTP终结点将在Azure Functions中使用HTTP触发器实现，并从此处使用其输出绑定机制将图像数据和作业请求信息分别存储在Blob存储和队列存储中。 我们之所以采用异步处理方法的原因是，通过这种方式，可以更轻松地按需扩展所需的处理单元。 例如，作业提交功能不是CPU绑定的任务，而是执行简单的数据存储操作。 而从Blob和队列存储中读取的图像处理功能将承担执行实际OCR操作的更昂贵且更耗时的任务。 因此，无服务器环境可以根据其需求扩展功能。
In the same manner, the result publishing function is separated from other tasks, since its email sending task can be a task with a high latency, which shouldn’t be an operation that should be blocking others. So it has its own result queue to retrieve result entries to be sent out using its capacity.
以相同的方式，结果发布功能与其他任务分开，因为它的电子邮件发送任务可以是具有高延迟的任务，而不应该是会阻塞其他任务的操作。 因此，它具有自己的结果队列，以使用其容量来检索要发送的结果条目。
实作 (Implementation)
Here, we will take a look at the Ballerina code that was used when implementing the Azure Functions solution.
在这里，我们将了解实现Azure Functions解决方案时使用的Ballerina代码。
作业提交 (Job Submission)
The submitJob function is the entry point to the system, where it defines an HTTP trigger to collect the user’s email address and take in the image data. Also, it defines blob and queue output binding to save the data that is collected. For the next function, it is just a matter of connecting wiring its input bindings to the output binding that is defined here.
SubmitJob函数是系统的入口点，它定义了一个HTTP触发器来收集用户的电子邮件地址并获取图像数据。 此外，它定义了Blob和队列输出绑定以保存收集的数据。 对于下一个功能，只需将其输入绑定连接到此处定义的输出绑定即可。
处理图像 (Processing Images)
The actual OCR operation happens in the processImage function. It starts off by defining the queue trigger to listen to the job entries that were added by the submitJob function. Additionally, it adds a blob input binding, which defines a parameterized path parameter that reads in the job ID from the trigger data. It also defines an output binding for a queue which will contain the final result along with the email address to where it should be sent to. The Azure Computer Vision connector is used here for the OCR operation, where its API key is looked up through an environment variable, which is set using an application setting in Azure.
实际的OCR操作发生在processImage函数中。 它通过定义队列触发器开始，以监听由SubmitJob函数添加的作业条目。 此外，它添加了Blob输入绑定，该绑定定义了一个参数化的路径参数，该参数从触发数据中读取作业ID。 它还为队列定义了输出绑定，该绑定将包含最终结果以及应将其发送到的电子邮件地址。 此处将Azure计算机视觉连接器用于OCR操作，其中通过环境变量查找其API密钥，该环境变量是使用Azure中的应用程序设置进行设置的。
After the results are published to the output queue, it is up to the next function to pick it up and send it out to the users.
将结果发布到输出队列后，将由下一个函数来选择并将其发送给用户。
发布结果 (Publish Results)
Here, the publishResults function defines a queue trigger to listen to the result publication queue. As and when an entry is available, this function is called to send out an email with the given address in the job information and the results of the OCR operation. Here, we have used the Gmail connector in order to send out the email.
在这里， publishResults函数定义一个队列触发器以侦听结果发布队列。 当有条目可用时，将调用此函数以发送一封电子邮件，该电子邮件中包含作业信息和OCR操作的结果中的给定地址。 在这里，我们已使用Gmail连接器来发送电子邮件。
This marks the end of the process, where we saw how the functions were conveniently wired together through the triggers and the bindings to provide a highly usable approach in defining integrations between systems.
这标志着过程的结束，我们看到了如何通过触发器和绑定将功能方便地连接在一起，从而为定义系统之间的集成提供了一种高度可用的方法。
部署方式 (Deployment)
先决条件 (Prerequisites)
- Azure Storage Services Azure存储服务
- Azure Cognitive Services — create a “Computer Vision” service in “East US” region Azure认知服务—在“美国东部”地区创建“计算机视觉”服务
Generate GMail API keys — instructions found here
生成GMail API密钥- 此处提供了说明
The full source code for the project can be found here.
该项目的完整源代码可以在这里找到。
The Ballerinalang compiler automatically builds the Azure Functions zip artifact to be deployed through the Azure CLI. Listing 4 shows a sample execution of the compilation, deployment, and a sample run. Finally, figure 2 shows the email received by the user with the job result.
Ballerinalang编译器会自动生成Azure Functions zip工件，以通过Azure CLI进行部署。 清单4显示了编译，部署和示例运行的示例执行。 最后，图2显示了用户收到的包含工作结果的电子邮件。
Note: If you are using Ballerina 1.2.6, please apply this patch — which contains the fix for this issue.
注意：如果您使用的是Ballerina 1.2.6，请应用此修补程序-包含针对此问题的修复程序。
摘要 (Summary)
The OCR scenario mentioned here is merely done to simulate potential time-consuming processing that you would have to do. This provides a reference implementation and a pattern on how we can easily create complex workflows by utilizing a serverless framework such as Azure Functions, where its bindings concept specifically allows us to streamline our operations.
此处提到的OCR方案仅用于模拟您可能必须执行的耗时的处理。 这提供了有关如何通过利用无服务器框架(如Azure Functions)轻松创建复杂工作流的参考实现和模式，该框架的绑定概念明确允许我们简化操作。
As a comparison, the Ballerinalang Azure Functions implementation is just a single source file with 60 lines, where its similar Kubernetes solution ended up with a multi-module project with 220 lines of code, and multiple configuration files. So we can see how the serverless frameworks have elevated the abstraction level for developers, allowing them to simply concentrate on the business logic.
相比之下，Ballerinalang Azure Functions实现只是一个包含60行的单个源文件，其类似的Kubernetes解决方案最终得到了一个包含220行代码和多个配置文件的多模块项目。 因此，我们可以看到无服务器框架如何提高了开发人员的抽象水平，使他们可以仅专注于业务逻辑。
For more information on writing serverless functions in Ballerinalang, check out the following resources:
有关在Ballerinalang中编写无服务器功能的更多信息，请查看以下资源：
ocr识别处理 解决方案
