dev
|
@ -16,7 +16,7 @@ export default defineConfig({
|
|||
// https://vitepress.dev/reference/default-theme-config
|
||||
nav: [
|
||||
{ text: 'Home', link: '/' },
|
||||
{ text: '概述', link: '/overview' },
|
||||
{ text: '概述', link: '/overview/micro-service' },
|
||||
{ text: '基础组件', link: '/infra' },
|
||||
{ text: '基础服务', link: '/base' },
|
||||
{ text: '应用服务', link: '/app' },
|
||||
|
|
|
@ -1,49 +0,0 @@
|
|||
---
|
||||
outline: deep
|
||||
---
|
||||
|
||||
# Runtime API Examples
|
||||
|
||||
This page demonstrates usage of some of the runtime APIs provided by VitePress.
|
||||
|
||||
The main `useData()` API can be used to access site, theme, and page data for the current page. It works in both `.md` and `.vue` files:
|
||||
|
||||
```md
|
||||
<script setup>
|
||||
import { useData } from 'vitepress'
|
||||
|
||||
const { theme, page, frontmatter } = useData()
|
||||
</script>
|
||||
|
||||
## Results
|
||||
|
||||
### Theme Data
|
||||
<pre>{{ theme }}</pre>
|
||||
|
||||
### Page Data
|
||||
<pre>{{ page }}</pre>
|
||||
|
||||
### Page Frontmatter
|
||||
<pre>{{ frontmatter }}</pre>
|
||||
```
|
||||
|
||||
<script setup>
|
||||
import { useData } from 'vitepress'
|
||||
|
||||
const { site, theme, page, frontmatter } = useData()
|
||||
</script>
|
||||
|
||||
## Results
|
||||
|
||||
### Theme Data
|
||||
<pre>{{ theme }}</pre>
|
||||
|
||||
### Page Data
|
||||
<pre>{{ page }}</pre>
|
||||
|
||||
### Page Frontmatter
|
||||
<pre>{{ frontmatter }}</pre>
|
||||
|
||||
## More
|
||||
|
||||
Check out the documentation for the [full list of runtime APIs](https://vitepress.dev/reference/runtime-api#usedata).
|
|
@ -1,85 +0,0 @@
|
|||
# Markdown Extension Examples
|
||||
|
||||
This page demonstrates some of the built-in markdown extensions provided by VitePress.
|
||||
|
||||
## Syntax Highlighting
|
||||
|
||||
VitePress provides Syntax Highlighting powered by [Shiki](https://github.com/shikijs/shiki), with additional features like line-highlighting:
|
||||
|
||||
**Input**
|
||||
|
||||
````md
|
||||
```js{4}
|
||||
export default {
|
||||
data () {
|
||||
return {
|
||||
msg: 'Highlighted!'
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
````
|
||||
|
||||
**Output**
|
||||
|
||||
```js{4}
|
||||
export default {
|
||||
data () {
|
||||
return {
|
||||
msg: 'Highlighted!'
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## Custom Containers
|
||||
|
||||
**Input**
|
||||
|
||||
```md
|
||||
::: info
|
||||
This is an info box.
|
||||
:::
|
||||
|
||||
::: tip
|
||||
This is a tip.
|
||||
:::
|
||||
|
||||
::: warning
|
||||
This is a warning.
|
||||
:::
|
||||
|
||||
::: danger
|
||||
This is a dangerous warning.
|
||||
:::
|
||||
|
||||
::: details
|
||||
This is a details block.
|
||||
:::
|
||||
```
|
||||
|
||||
**Output**
|
||||
|
||||
::: info
|
||||
This is an info box.
|
||||
:::
|
||||
|
||||
::: tip
|
||||
This is a tip.
|
||||
:::
|
||||
|
||||
::: warning
|
||||
This is a warning.
|
||||
:::
|
||||
|
||||
::: danger
|
||||
This is a dangerous warning.
|
||||
:::
|
||||
|
||||
::: details
|
||||
This is a details block.
|
||||
:::
|
||||
|
||||
## More
|
||||
|
||||
Check out the documentation for the [full list of markdown extensions](https://vitepress.dev/guide/markdown).
|
|
@ -1,85 +0,0 @@
|
|||
# Markdown Extension Examples
|
||||
|
||||
This page demonstrates some of the built-in markdown extensions provided by VitePress.
|
||||
|
||||
## Syntax Highlighting
|
||||
|
||||
VitePress provides Syntax Highlighting powered by [Shiki](https://github.com/shikijs/shiki), with additional features like line-highlighting:
|
||||
|
||||
**Input**
|
||||
|
||||
````md
|
||||
```js{4}
|
||||
export default {
|
||||
data () {
|
||||
return {
|
||||
msg: 'Highlighted!'
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
````
|
||||
|
||||
**Output**
|
||||
|
||||
```js{4}
|
||||
export default {
|
||||
data () {
|
||||
return {
|
||||
msg: 'Highlighted!'
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## Custom Containers
|
||||
|
||||
**Input**
|
||||
|
||||
```md
|
||||
::: info
|
||||
This is an info box.
|
||||
:::
|
||||
|
||||
::: tip
|
||||
This is a tip.
|
||||
:::
|
||||
|
||||
::: warning
|
||||
This is a warning.
|
||||
:::
|
||||
|
||||
::: danger
|
||||
This is a dangerous warning.
|
||||
:::
|
||||
|
||||
::: details
|
||||
This is a details block.
|
||||
:::
|
||||
```
|
||||
|
||||
**Output**
|
||||
|
||||
::: info
|
||||
This is an info box.
|
||||
:::
|
||||
|
||||
::: tip
|
||||
This is a tip.
|
||||
:::
|
||||
|
||||
::: warning
|
||||
This is a warning.
|
||||
:::
|
||||
|
||||
::: danger
|
||||
This is a dangerous warning.
|
||||
:::
|
||||
|
||||
::: details
|
||||
This is a details block.
|
||||
:::
|
||||
|
||||
## More
|
||||
|
||||
Check out the documentation for the [full list of markdown extensions](https://vitepress.dev/guide/markdown).
|
|
@ -0,0 +1,56 @@
|
|||
# Blocks Service Mesh 概述
|
||||
|
||||
Blocks Service Mesh 是一个融合了 Service Mesh 和 Microservice 的技术解决方案,它基于 Service Mesh 的概念,通过在微服务框架中加入 Service Mesh 的能力,为微服务架构提供更科学的服务治理能力。
|
||||
|
||||
# 创业型企业不应该使用大构架
|
||||
|
||||
在互联网开发领域,创业型小企业采用大构架(即大型、复杂的系统架构)可能会面临一系列问题。以下是一些小企业不应该使用大构架的观点:
|
||||
|
||||
1. **成本问题**:
|
||||
- **开发成本**:大构架通常需要更多的开发资源和时间,这会增加小企业的初始成本。
|
||||
- **维护成本**:随着系统的复杂度增加,维护和更新的成本也会相应增加。
|
||||
|
||||
2. **灵活性缺失**:
|
||||
- **快速迭代**:小企业通常需要快速迭代产品以适应市场变化,而大构架可能会限制这种灵活性。
|
||||
- **快速响应**:在面对市场变化或客户需求时,大构架可能难以快速调整。
|
||||
|
||||
3. **技术债务**:
|
||||
- **复杂性**:大构架可能会引入不必要的复杂性,导致技术债务的积累。
|
||||
- **学习曲线**:新员工需要更多的时间来学习和理解复杂的系统架构。
|
||||
|
||||
4. **资源分散**:
|
||||
- **专注度**:小企业资源有限,大构架可能导致资源分散,无法专注于核心业务。
|
||||
- **效率降低**:过多的精力投入到架构上,可能会降低开发效率。
|
||||
|
||||
5. **风险增加**:
|
||||
- **失败风险**:大构架的失败可能导致整个项目的失败,风险较高。
|
||||
- **依赖风险**:大构架可能过度依赖某些技术或供应商,增加依赖风险。
|
||||
|
||||
6. **可扩展性误区**:
|
||||
- **过早优化**:小企业可能会过早地为未来的扩展性做优化,而实际上这种扩展性可能永远不会需要。
|
||||
|
||||
7. **团队规模**:
|
||||
- **团队适应性**:小团队可能难以管理复杂的大构架,导致沟通和协作问题。
|
||||
|
||||
8. **市场适应性**:
|
||||
- **市场变化**:小企业需要快速适应市场变化,而大构架可能限制了这种适应性。
|
||||
|
||||
9. **创新障碍**:
|
||||
- **创新限制**:大构架可能会限制创新,因为团队需要在现有框架内工作。
|
||||
|
||||
10. **客户体验**:
|
||||
- **复杂性影响**:过于复杂的系统可能会影响用户体验。
|
||||
|
||||
**建议**:
|
||||
- **敏捷开发**:采用敏捷开发方法,快速迭代,逐步构建系统。
|
||||
- **微服务架构**:考虑使用微服务架构,它允许更灵活的服务部署和扩展。
|
||||
- **模块化设计**:设计模块化的系统,便于维护和扩展。
|
||||
- **云服务**:利用云服务提供商的资源,按需扩展,减少前期投资。
|
||||
- **持续集成/持续部署(CI/CD)**:实现自动化的测试和部署流程,提高开发效率。
|
||||
|
||||
|
||||
|
||||
# Blocks Service Mesh 解决方案
|
||||
|
||||
![Blocks Service Mesh](/bp/BlocksMesh_v3_01.png)
|
||||
![Blocks Service Mesh](/bp/BlocksMesh_v3_02.png)
|
|
@ -0,0 +1,29 @@
|
|||
# 微服务架构 概述
|
||||
|
||||
微服务架构是一种软件开发方法,它将应用程序分解为一组小型、松散耦合的服务,每个服务实现特定的业务功能,并且可以独立部署和扩展。这种架构风格提高了软件系统的可维护性、可扩展性和灵活性。
|
||||
|
||||
## 微服务架构关键特点:
|
||||
|
||||
服务拆分:应用程序被拆分为多个小服务,每个服务负责一部分业务功能。
|
||||
|
||||
独立部署:每个微服务可以独立部署,不需要与其他服务一起部署。
|
||||
|
||||
技术多样性:不同的服务可以使用不同的编程语言、数据库或其他技术栈。
|
||||
|
||||
业务能力:每个服务围绕特定的业务能力构建,具有明确的职责。
|
||||
|
||||
轻量级通信:服务之间通常通过轻量级的通信机制(如HTTP RESTful API或gRPC)进行交互。
|
||||
|
||||
去中心化治理:每个服务可以独立地进行版本控制、部署和扩展。
|
||||
|
||||
敏捷性:微服务架构支持敏捷开发,因为团队可以独立地开发和部署服务。
|
||||
|
||||
容错性:通过设计,微服务架构可以提高系统的容错性,即使某个服务失败,其他服务仍然可以继续运行。
|
||||
|
||||
可扩展性:可以根据需求独立地扩展服务。
|
||||
|
||||
持续部署和持续集成(CI/CD):微服务架构支持持续集成和持续部署,使得频繁的代码提交和部署成为可能。
|
||||
|
||||
服务发现:在分布式系统中,服务需要能够找到彼此,服务发现机制可以帮助实现这一点。
|
||||
|
||||
API网关:通常使用API网关作为系统的入口点,它负责请求路由、负载均衡和安全控制。
|
|
@ -0,0 +1,37 @@
|
|||
# Service Mesh 概述
|
||||
|
||||
在云原生架构中,Service Mesh 技术是一种用于管理微服务架构中服务间通信的解决方案,它由一组轻量级的网络代理组成,这些代理被部署在应用程序内的每个服务实例旁边,并负责处理与其他服务之间的通信。通过在数据平面中拦截和管理流量,Service Mesh 提供了一种集中式的方式来实现高级网络功能,比如服务发现、负载均衡、故障恢复、安全性和监控。
|
||||
|
||||
## Service Mesh 的核心组件
|
||||
|
||||
Service Mesh的架构通常包括以下几个核心组件:
|
||||
|
||||
数据平面(Data Plane):
|
||||
|
||||
Sidecar Proxy:每个服务实例旁边运行的代理,负责拦截出入的网络流量并执行流量管理、安全策略等操作。常见的Sidecar Proxy包括Envoy、Linkerd-proxy等。
|
||||
Service Proxy:在某些实现中,代理可能直接嵌入到服务实例中,作为服务的一部分运行。
|
||||
控制平面(Control Plane):
|
||||
|
||||
配置管理:提供统一的配置管理接口,用于下发和管理数据平面的配置。常见的控制平面包括Istio的Pilot、Linkerd的Controller等。
|
||||
服务发现:管理服务注册和发现,确保代理能够正确路由流量。
|
||||
策略管理:用于定义和下发流量管理、安全认证、访问控制等策略。
|
||||
可观察性组件:负责收集和聚合服务网格中的监控数据、日志和追踪信息,提供可视化和报警功能。
|
||||
|
||||
## Service Mesh 的工作原理
|
||||
Service Mesh通过在每个服务实例旁边部署Sidecar Proxy,实现了对服务间通信的透明代理。这些代理负责拦截出入的所有流量,并根据控制平面下发的配置和策略执行相应的操作。具体工作原理如下:
|
||||
|
||||
服务发现:
|
||||
|
||||
当一个服务实例启动时,它会向服务注册中心注册自己的信息。控制平面负责管理这些服务实例信息,并将更新的服务列表分发给所有Sidecar Proxy。
|
||||
流量管理:
|
||||
|
||||
当一个服务需要与另一个服务通信时,流量首先经过本地的Sidecar Proxy。代理根据配置的路由规则和负载均衡策略,将流量转发到目标服务实例。
|
||||
控制平面可以动态更新这些路由规则,实现蓝绿部署、金丝雀发布等高级流量管理功能。
|
||||
安全认证:
|
||||
|
||||
Service Mesh可以在服务间通信中引入双向TLS加密,确保数据在传输过程中不被篡改和窃听。控制平面负责管理和分发证书,Sidecar Proxy在通信过程中进行加密和解密操作。
|
||||
通过引入身份认证和访问控制策略,可以细粒度地控制哪些服务可以访问其他服务。
|
||||
可观察性:
|
||||
|
||||
Service Mesh中的代理会收集每个请求的日志、监控数据和追踪信息,并将这些数据发送到可观察性组件进行处理和存储。
|
||||
运维人员可以通过控制平面提供的接口和仪表盘,实时监控服务间的流量情况、延迟、错误率等指标,并进行故障排查和性能优化。
|
After Width: | Height: | Size: 1.9 MiB |
After Width: | Height: | Size: 1.9 MiB |
After Width: | Height: | Size: 687 KiB |
After Width: | Height: | Size: 522 KiB |
After Width: | Height: | Size: 1.9 MiB |
After Width: | Height: | Size: 486 KiB |
After Width: | Height: | Size: 445 KiB |
After Width: | Height: | Size: 465 KiB |
After Width: | Height: | Size: 422 KiB |
After Width: | Height: | Size: 1.9 MiB |
After Width: | Height: | Size: 777 KiB |
After Width: | Height: | Size: 708 KiB |
After Width: | Height: | Size: 449 KiB |
After Width: | Height: | Size: 471 KiB |
After Width: | Height: | Size: 1.9 MiB |
After Width: | Height: | Size: 531 KiB |
After Width: | Height: | Size: 448 KiB |
After Width: | Height: | Size: 429 KiB |