HTML常用特殊字符 ：只要你认识了 HTML 标记，你便会知道特殊字符的用处。

常用标点

箭头类

基本形状类

货币类

字母符号

数学类

音乐符号类

对错号

全都是星星

星座类

国际象棋类

扑克牌类

希腊字母

十字

法律符号

标点和符号

希腊文和科普特文

Multi Tenancy usually plays an important role in the business case for SAAS solutions. Spring Boot and Hibernate provide out-of-the-box support for different Multi-tenancy strategies. Configuration however becomes more complicated, and the available code examples are limited. In the first part of this blog series, we’ll start by exploring the Multi Tenancy concept and three different architectural patterns for multi tenant data isolation. In the forthcoming episodes, we’ll deep dive into the details of implementing the different patterns usign Spring Boot, Spring Data and Liquibase.

BLOG SERIES PARTS

• Part 1: What is Multi Tenancy (this part)
• Part 2: Outlining an Implementation Strategy for Multi Tenant Data Access
• Part 3: Implementing the Database per Tenant pattern
• Part 4: Implementing the Schema per Tenant pattern
• Part 5: Implementing the Shared database with Discriminator Column pattern using Hibernate Filters
• Part 6: Implementing the Shared database with Discriminator Column pattern using Postgres Row Level Security
• Part 7: Combining the Shared Database pattern with Database per Group of Tenants (a.k.a. Shard) for additional scalability
• Part 8: Shared Database pattern with Hibernate 6

WHAT IS MULTI TENANCY?

By allowing one single, highly scalable software solution to serve many different customers, a scalable, elastic, agile and cost effective solution can be built. A software architecture in which a (logically) single instance of the software serves multiple tenants is frequently called a _multi-tenancy_ architecture. A _tenant_ is a group of users who share a common access with specific privileges to the software instance. Everything should be shared, except for the different customers’ data, which should be properly separated. Despite the fact that they share resources, tenants aren’t aware of each other, and their data is kept totally separate.

CONFLICTING REQUIREMENTS

As usual with architectural patterns, a multi-tenant architecture has to balance two partly conflicting needs or forces: On one hand, we would like to share as much as possible, in order to achieve:

• Better use of resources: One machine reserved for one tenant isn’t efficient, as that one tenant is not likely to use all of the machine’s computing power. By sharing machines among multiple tenants, use of available resources is maximized.
• Lower costs: With multiple customers sharing resources, a vendor can offer their services to many customers at a much lower cost than if each customer required their own dedicated infrastructure.
• Elasticity and Agility: With a shared infrastructure, onboarding new tenants can be much easier, quicker and cost efficient.

On the other hand, we would like to have a fool-proof separation of between tenants, in order to guarantee the privacy, confidentiality and consistency of each tenant’s data. We also have to avoid the problem with “noisy neighbors”, where a tenant that misbehaves potentially can disturb its neighboring tenants.

MULTI TENANCY PATTERNS

As we can see, a challenge lies in separating the data for each tenant, while still sharing as much as possible of the other resources. Three principal architectural patterns for Multi Tenancy can be identified, which differs in the degree of (physical) separation of the tenant’s data.

• Database per tenant

The most obvious way to separate the data owned by different tenants is to use a separate database per tenant. Using this pattern, the data is physically isolated per tenant, and hence the privacy and confidentiality of the data can easily be guaranteed (including administrative housekeeping such as backups and cleansing). The tradeoff is equally obvious, since the database infrastructure as well as database connection pools cannot be shared between tenants.

• Schema per tenant

A slight variation to is to use a separate _database schema_ per tenant, while sharing the database instance. The data for each tenant is logically isolated by the semantics of separate schemas as provided by the database engine. If the schemas is owned by a separate database user per tenant, the database engine’s security mechanism further guarantee the privacy and confidentiality of the data (note however that in such a case, the database connection pool cannot be reused by the data access layer).

• Shared database, using a Discriminator Column

The final pattern uses a fully shared database, in which data for all tenants are stored in the same table(s). An additional _discriminator_ column is added to each table, which needs to be included in an additional where clause in each and every query. This pattern provides the least data separation (leaving it to the application to guarantee privacy and confidentiality for the tenant’s data) but the maximum sharing of resources. From an infrastructure perspective, it is the conceptually simplest solution, whereas the complexity is pushed into the application. Since data is not separated at the database level, administrative housekeeping such as backups per tenant becomes more difficult.

CHOOSING A MULTI TENANCY PATTERN

Hence there are different pro’s and con’s with the three patterns above. The choice between them will be governed by the requirements of a particular solution. Database-per-tenant provides very strong data isolation between tenants, but requires more infrastructural resources and administrative work in setting up new tenants and performing database migrations. Hence there is an upper limit on the scalability of the Database-per-tenant pattern, both in size and the time required to onboard new tenants. Shared-database-with-Discriminator-column provides maximal sharing of infrastructural resources and hence excellent scalability, but with data isolation between tenants only guaranteed by the application layer.

If you have a smaller number of tenants (< 1000) and require strong guarantees for tenant data isolation, Database-per-tenant and Schema-per-tenant are the most frequent choices. Among them, Schema-per-tenant is usually a good balance between data separation and resource sharing. If you have a large number of tenants, Shared-database-with-Discriminator-column might be the only viable solution.

Sometimes, the most pragmatic approach is a mixed model, supporting different customer segments using different models.

SUMMARY

In this blog post, we have explored the Multi Tenancy concept and discussed three different architectural patterns for multi tenant data isolation. In the next part, we’ll dive into an implementation strategy for for Multi Tenant Data Access using Spring Boot, Spring Data, Hibernate and Liquibase, that allows us to implement the different multi tenant patterns transparently and efficiently.

npm包版本号详解

npm包在发布时，需要按照包版本语义化中的约定去更新设置，例如我们常见的1.0.0，1.0.1，0.0.1等这样的版本号，那么这些数字分别代表什么意思呢？下面我们将详细介绍。

npm版本号的组成

一个完整的版本号，由三部分组成：主版本号（major）、次版本号(minor)、修订版本号(patch)，简称X.Y.Z，具体含义：

• 主版本号（major）：项目（包）做了大量的变更，与旧的版本存在一定的不兼容性等问题。
• 次版本号（minor）：做了少量的变更或向下做了兼容。
• 修订版本号（patch）：修复上一个版本的bug或向下做兼容。

版本号变更的一般规则：

• 版本号只升不降，不得在数字前面加0。例如不能是1.01.0，应该是1.0.0。
• 当主版本号升级时，次版本号和修订版本号需要归零。例如1.1.1->2.0.0。
• 当次版本号升级时，主版本号不变，修订版本号归零。例如1.1.1->1.2.0。
• 当修订版本号升级时，主版本和次版本号都不变。例如1.1.1->1.1.2。
• 一般第一个正式版本应为1.0.0。
• 处于开发测试阶段的版本一般为0.y.z，如果不发布，则默认为0.0.0，如果发布第一个测试版本则是0.1.0，如果修复第一个测试版本则是0.1.1，如果更新第二个测试版本则是0.2.0。

版本标识符（标签）

格式：Major.Minor.Patch-Identifier.1，其中Identifier就是代表标识符，和版本号之间使用-隔离，后面则是当前标识符的版本版本号，每升级一次则+1

希望安装带标签的版本，必须明确指定标签或者版本号，否则安装的是最新的不带标签的版本。

版本运算符

版本运算符一般是指定一定范围的版本号，主要有~、-、^、<、>等。

~ 版本号只指定主版本号或者次版本号，例如：

^ 版本号

匹配第一个非0版本号

npm 安装包时，默认使用 ^ 匹配版本。

~ 与 ^ 对比

跨域设置

Access-Control-Allow-Credentials

Access-Control-Allow-Credentials 响应头用于在请求要求包含 credentials（Request.credentials 的值为 include）时，告知浏览器是否可以将对请求的响应暴露给前端 JavaScript 代码。

当请求的 credentials 模式（Request.credentials）为 include 时，浏览器仅在响应标头 Access-Control-Allow-Credentials 的值为 true 的情况下将响应暴露给前端的 JavaScript 代码。

Credentials 可以是 cookies、authorization headers 或 TLS client certificates。

当作为对预检请求的响应的一部分时，这能表示是否真正的请求可以使用 credentials。注意简单的GET 请求没有预检，所以若一个对资源的请求带了 credentials，如果这个响应头没有随资源返回，响应就会被浏览器忽视，不会返回到 web 内容。

Access-Control-Allow-Credentials 标头需要与 XMLHttpRequest.withCredentials 或 Fetch API 的 Request() 构造函数中的 credentials 选项结合使用。Credentials 必须在前后端都被配置（即 Access-Control-Allow-Credentials header 和 XHR 或 Fetch request 中都要配置）才能使带 credentials 的 CORS 请求成功。

语法

Access-Control-Allow-Credentials: true

指令

true: 这个头的唯一有效值（区分大小写）。如果不需要 credentials，相比将其设为 false，请直接忽视这个头。

Access-Control-Allow-Headers

响应首部 Access-Control-Allow-Headers 用于 preflight request（预检请求）中，列出了将会在正式请求的 Access-Control-Request-Headers 字段中出现的首部信息。

简单首部，如 simple headers、Accept、Accept-Language、Content-Language、Content-Type（只限于解析后的值为 application/x-www-form-urlencoded、multipart/form-data 或 text/plain 三种 MIME 类型（不包括参数）），它们始终是被支持的，不需要在这个首部特意列出。

如果请求中含有 Access-Control-Request-Headers 字段，那么这个首部是必要的。

语法

Access-Control-Allow-Headers: <header-name>[, <header-name>]*
Access-Control-Allow-Headers: *

指令

<header-name>: 可支持的请求首部名字。请求头会列出所有支持的首部列表，用逗号隔开。

注意以下这些特定的首部是一直允许的：Accept, Accept-Language, Content-Language, Content-Type（但只在其值属于 MIME 类型 application/x-www-form-urlencoded, multipart/form-data 或 text/plain中的一种时）。这些被称作simple headers，你无需特意声明它们。

* (wildcard)

对于没有凭据的请求（没有 HTTP cookie 或 HTTP 认证信息的请求），值“*”仅作为特殊的通配符值。在具有凭据的请求中，它被视为没有特殊语义的文字标头名称“*”。请注意，Authorization标头不能使用通配符，并且始终需要明确列出。

Access-Control-Allow-Methods

响应首部 Access-Control-Allow-Methods 在对 preflight request.（预检请求）的应答中明确了客户端所要访问的资源允许使用的方法或方法列表。

语法

Access-Control-Allow-Methods: <method>, <method>, ...

指令

<method>: 用逗号隔开的允许使用的 HTTP request methods 列表。

• GET: GET 方法请求一个指定资源的表示形式，使用 GET 的请求应该只被用于获取数据。
• HEAD: HEAD 方法请求一个与 GET 请求的响应相同的响应，但没有响应体。
• POST: POST 方法用于将实体提交到指定的资源，通常导致在服务器上的状态变化或副作用。
• PUT: PUT 方法用请求有效载荷替换目标资源的所有当前表示。
• DELETE: DELETE 方法删除指定的资源。
• CONNECT: CONNECT 方法建立一个到由目标资源标识的服务器的隧道。
• OPTIONS: OPTIONS 方法用于描述目标资源的通信选项。
• TRACE: TRACE 方法沿着到目标资源的路径执行一个消息环回测试。
• PATCH: PATCH 方法用于对资源应用部分修改。

Access-Control-Allow-Origin

Access-Control-Allow-Origin 响应标头指定了该响应的资源是否被允许与给定的来源（origin）共享。

语法

Access-Control-Allow-Origin: *
Access-Control-Allow-Origin: <origin>
Access-Control-Allow-Origin: null

Nginx配置

set $cors_origin '';
if ($http_origin ~* "lavecoral.me$") {
    set $cors_origin '$http_origin';
}

add_header Access-Control-Allow-Origin '$cors_origin';
add_header Access-Control-Allow-Credentials true;
add_header Access-Control-Allow-Methods 'GET, PUT, DELETE, PATCH, POST, OPTIONS';
add_header Access-Control-Allow-Headers 'Authorization,X-Requested-With';

if ($request_method = 'OPTIONS') {
    return 204;
}

正常ts文件都要编译成JS文件才能运行，但是在开发时有时需要运行ts文件，但是每次都要配置package.json，还要安装，后来看到ts-node可以在vscode上运行ts文件。

安装环境

//全局安装typescript和ts-node
npm install -g typescript
//npm install -g typescript-node 由于typescript-node不支持更高版本的ts
npm install -g ts-node //typescript@>=2.7

安装完成后就可以不用手动去编译成js文件，可以直接运行ts文件

//foo.ts
let foo = {
  baz: {
    a: 1
  }
}
console.log(foo);

执行命令ts-node **.ts

$ ts-node foo.ts
{ baz: { a: 1 } }