tess 英文字库(eng.traineddata)

Tesseractocr英文字库最新eng.traineddata英文tessdata。据我所知，Tesseract 3.x带有6种英语(如果我输入错了，请纠正我)字体.我需要训练Tesseract以获取更多5种类型的字体.我只需要大写字母和数字(不需要特殊字符或符号).

例如，我遵循各种过程: 为Tesseract 3 OCR引擎添加新字体 。

文件：url80.ctfile.com/f/25127180-741353087-9da402?p=551685 (访问密码: 551685)

---

在传统的虚机/物理机环境里, 如果我们想要对一个有状态应用扩容, 我们需要做哪些步骤?

申请虚机/物理机
安装依赖
下载安装包
按规范配置主机名, hosts
配置网络: 包括域名, DNS, 虚 ip, 防火墙…
配置监控
今天虚机环境上出现了问题, 是因为 RabbitMQ 资源不足. 手动扩容的过程中花费了较长的时间.

但是在 K8S 上, 有状态应用的扩容就很简单, YAML 里改一下replicas副本数, 等不到 1min 就扩容完毕.

当然, 最基本的: 下镜像, 启动 pod(相当于上边的前 3 步), 就不必多提. 那么, 还有哪些因素, 让有状态应用可以在 k8s 上快速扩容甚至自动扩容呢?

原因就是这两点:

peer discovery +peer discovery 的 相关实现(通过 hostname, dns, k8s api 或其他)
可观察性 + 自动伸缩
我们今天选择几个典型的有状态应用, 一一梳理下:

Eureka
Nacos
Redis
RabbitMQ
Kafka
TiDB
K8S 上有状态应用扩容
在 Kubernetes 上, 有状态应用快速扩容甚至自动扩容很容易. 这得益于 Kubernetes 优秀的设计以及良好的生态. Kubernetes 就像是一个云原生时代的操作系统. 它自身就具有:

自动化工具;
内部服务发现 + 负载均衡
内部 DNS
和 Prometheus 整合
统一的声明式 API
标准, 开源的生态环境.
所以, 需要扩容, 一个 yaml 搞定全部. 包括上边提到的: 下载, 安装, 存储配置, 节点发现, 加入集群, 监控配置…

Eureka 扩容
eureka

🔖 备注:

有状态扩容第一层:

StatefulSet + Headless Service

eureka 的扩容在 K8S 有状态应用中是最简单的, 就是:

headless service + statefulset

Eureka 要扩容, 只要 eureka 实例彼此能相互发现就可以. headless service 在这种情况下就派上用场了, 就是让彼此发现.

Eureka 的一个完整集群 yaml, 如下:详细说明如下:

apiVersion: v1
kind: Service
metadata:
name: eureka
namespace: ms
spec:
clusterIP: None
ports:
- name: eureka
port: 8888
selector:
project: ms
app: eureka

apiVersion: apps/v1
kind: StatefulSet
metadata:
name: eureka
namespace: ms
spec:
serviceName: eureka
replicas: 3
selector:
matchLabels:
project: ms
app: eureka
template:
metadata:
labels:
project: ms
app: eureka
spec:
terminationGracePeriodSeconds: 10
imagePullSecrets:
- name: registry-pull-secret
containers:
- name: eureka
image: registry.example.com/kubernetes/eureka:latest
ports:
- protocol: TCP
containerPort: 8888
env:
- name: APP_NAME
value: “eureka”
- name: POD_NAME
valueFrom:
fieldRef:
fieldPath: metadata.name
- name: APP_OPTS
value: "
–eureka.instance.hostname=

P

O

D

N

A

M

E

.

{POD_NAME}.

PODN​AME.{APP_NAME}
–registerWithEureka=true
–fetchRegistry=true
–eureka.instance.preferIpAddress=false
–eureka.client.serviceUrl.defaultZone=http://eureka-0.

A

P

P

N

A

M

E

:

8888

/

e

u

r

e

k

a

/

,

h

t

t

p

:

/

/

e

u

r

e

k

a

−

1.

{APP_NAME}:8888/eureka/,http://eureka-1.

APPN​AME:8888/eureka/,http://eureka−1.{APP_NAME}:8888/eureka/,http://eureka-2.${APP_NAME}:8888/eureka/
配置名为eureka的 Service
在名为eureka的 statefulset 配置下,共 3 个 eureka 副本, 每个 eureka 的 HOSTNAME 为:

P

O

D

N

A

M

E

.

{POD_NAME}.

PODN​AME.{SERVICE_NAME}. 如: eureka-0.eureka
彼此通过–registerWithEureka=true --fetchRegistry=true --eureka.instance.preferIpAddress=false --eureka.client.serviceUrl.defaultZone=http://eureka-0.

A

P

P

N

A

M

E

:

8888

/

e

u

r

e

k

a

/

,

h

t

t

p

:

/

/

e

u

r

e

k

a

−

1.

{APP_NAME}:8888/eureka/,http://eureka-1.

APPN​AME:8888/eureka/,http://eureka−1.{APP_NAME}:8888/eureka/,http://eureka-2.${APP_NAME}:8888/eureka/通过 HOSTNAME 相互注册, 完成了集群的创建.
那么, 如果要快速扩容到 5 个:

调整 StatefulSet: replicas: 5
在环境变量APP_OPTS中加入新增的 2 个副本 hostname: http://eureka-3.

A

P

P

N

A

M

E

:

8888

/

e

u

r

e

k

a

/

,

h

t

t

p

:

/

/

e

u

r

e

k

a

−

4.

{APP_NAME}:8888/eureka/,http://eureka-4.

APPN​AME:8888/eureka/,http://eureka−4.{APP_NAME}:8888/eureka/
即可完成.

Headless Service
有时不需要或不想要负载均衡，以及单独的 Service IP。 遇到这种情况，可以通过指定 Cluster IP（spec.clusterIP）的值为 None 来创建 Headless Service。

您可以使用无头 Service 与其他服务发现机制进行接口，而不必与 Kubernetes 的实现捆绑在一起。

对这无头 Service 并不会分配 Cluster IP，kube-proxy 不会处理它们， 而且平台也不会为它们进行负载均衡和路由。 DNS 如何实现自动配置，依赖于 Service 是否定义了选择算符。

Nacos
nacos

🔖 备注:

有状态扩容第二层:

StatefulSet + Headless Service + Init Container(自动化发现) + PVC

相比 Eureka, nacos 通过一个init container,(这个 init container, 就是一个自动化的 peer discovery 脚本.) , 实现了一行命令快速扩容:

kubectl scale sts nacos --replicas=3
脚本链接为: https://github.com/nacos-group/nacos-k8s/tree/master/plugin/peer

扩容的相关自动化操作为:

从 Headless Service 自动发现所有的 replicas 的 HOSTNAME;
并将 HOSTNAME 写入到: ${CLUSTER_CONF} 这个文件下.
${CLUSTER_CONF}这个文件就是 nacos 集群的所有 member 信息. 将新写入 HOSTNAME 的实例加入到 nacos 集群中.
在这里, 通过 Headless Service 和 PV/PVC(存储 nacos 插件或其他数据)，实现了对 Pod 的拓扑状态和存储状态的维护，从而让用户可以在 Kubernetes 上运行有状态的应用。

然而 Statefullset 只能提供受限的管理，通过 StatefulSet 我们还是需要编写复杂的脚本(如 nacos 的peer-finder相关脚本), 通过判断节点编号来区别节点的关系和拓扑，需要关心具体的部署工作。

RabbitMQ
rabbitmq

🔖 备注:

有状态扩容第三层:

StatefulSet + Headless Service + 插件(自动化发现和监控) + PVC

RabbitMQ 的集群可以参考这边官方文档: Cluster Formation and Peer Discovery

这里提到的, 动态的发现机制需要依赖外部的服务, 如: DNS, API(AWS 或 K8S).

对于 Kubernetes, 使用的动态发现机制是基于rabbitmq-peer-discovery-k8s插件 实现的.

通过这种机制，节点可以使用一组配置的值从 Kubernetes API 端点获取其对等方的列表：URI 模式，主机，端口以及令牌和证书路径。

另外, rabbitmq 镜像也默认集成了监控的插件 - rabbitmq_prometheus.

当然, 通过Helm Chart也能一键部署和扩容.

Helm Chart
一句话概括, Helm 之于 Kubernetes, 相当于 yum 之于 centos. 解决了依赖的问题. 将部署 rabbitmq 这么复杂的软件所需要的一大堆 yaml, 通过参数化抽象出必要的参数(并且提供默认参数)来快速部署.

Redis
redis

🔖 备注:

有状态扩容第四层:

通过 Operator 统一编排和管理:

Deployment(哨兵) + StatefulSet + Headless Service + Sidecar Container(监控) + PVC

这里以 UCloud 开源的: redis-operator 为例. 它是基于 哨兵模式 的 redis 集群.

于之前的 StatefulSet + Headless 不同, 这里用到了一项新的 K8S 技术: operator.

Operator 原理
📖 说明:

解释 Operator 不得不提 Kubernetes 中两个最具价值的理念：“声明式 API” 和 “控制器模式”。“声明式 API”的核心原理就是当用户向 Kubernetes 提交了一个 API 对象的描述之后，Kubernetes 会负责为你保证整个集群里各项资源的状态，都与你的 API 对象描述的需求相一致。Kubernetes 通过启动一种叫做“控制器模式”的无限循环，WATCH 这些 API 对象的变化，不断检查，然后调谐，最后确保整个集群的状态与这个 API 对象的描述一致。

比如 Kubernetes 自带的控制器：Deployment，如果我们想在 Kubernetes 中部署双副本的 Nginx 服务，那么我们就定义一个 repicas 为 2 的 Deployment 对象，Deployment 控制器 WATCH 到我们的对象后，通过控制循环，最终会帮我们在 Kubernetes 启动两个 Pod。

Operator 是同样的道理，以我们的 Redis Operator 为例，为了实现 Operator，我们首先需要将自定义对象的说明注册到 Kubernetes 中，这个对象的说明就叫 CustomResourceDefinition（CRD），它用于描述我们 Operator 控制的应用：redis 集群，这一步是为了让 Kubernetes 能够认识我们应用。然后需要实现自定义控制器去 WATCH 用户提交的 redis 集群实例，这样当用户告诉 Kubernetes 我想要一个 redis 集群实例后，Redis Operator 就能够通过控制循环执行调谐逻辑达到用户定义状态。

简单说, operator 可以翻译为: 运维人（操作员） . 就是将高级原厂运维专家多年的经验, 浓缩为一个: operator. 那么, 我们所有的 运维打工人 就不需要再苦哈哈的"从零开始搭建 xxx 集群", 而是通过这个可扩展、可重复、标准化、甚至全生命周期运维管理的operator。 来完成复杂软件的安装，扩容，监控, 备份甚至故障恢复。

Redis Operator
使用 Redis Operator 我们可以很方便的起一个哨兵模式的集群，集群只有一个 Master 节点，多个 Slave 节点，假如指定 Redis 集群的 size 为 3，那么 Redis Operator 就会帮我们启动一个 Master 节点，两个 Salve 节点，同时启动三个 Sentinel 节点来管理 Redis 集群：

redis operator 哨兵架构

Redis Operator 通过 Statefulset 管理 Redis 节点，通过 Deployment 来管理 Sentinel 节点，这比管理裸 Pod 要容易，节省实现成本。同时创建一个 Service 指向所有的哨兵节点，通过 Service 对客户端提供查询 Master、Slave 节点的服务。最终，Redis Operator 控制循环会调谐集群的状态，设置集群的拓扑，让所有的 Sentinel 监控同一个 Master 节点，监控相同的 Salve 节点，Redis Operator 除了会 WATCH 实例的创建、更新、删除事件，还会定时检测已有的集群的健康状态，实时把集群的状态记录到 spec.status.conditions 中.

同时, 还提供了快速持久化, 监控, 自动化 redis 集群配置的能力. 只需一个 yaml 即可实现:

apiVersion: redis.kun/v1beta1
kind: RedisCluster
metadata:
name: redis
spec:
config: # redis集群配置
maxmemory: 1gb
maxmemory-policy: allkeys-lru
password: sfdfghc56s # redis密码配置
resources: # redis资源配置
limits:
cpu: ‘1’
memory: 1536Mi
requests:
cpu: 250m
memory: 1Gi
size: 3 # redis副本数配置
storage: # 持久化存储配置
keepAfterDeletion: true
persistentVolumeClaim:
metadata:
name: redis
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 5Gi
storageClassName: nfs
volumeMode: Filesystem
sentinel: # 哨兵配置
image: ‘redis:5.0.4-alpine’
exporter: # 启用监控
enabled: true
要扩容也很简单, 将上边的size: 3按需调整即可. 调整后, 自动申请资源, 扩容, 加存储, 改 redis 配置, 加入 redis 集群, 并且自动添加监控.