test/hyperf
1
0
Fork 0
mirror of https://gitee.com/hyperf/hyperf.git synced 2024-12-03 20:27:59 +08:00
Code Issues Actions 16 Packages Projects Releases Wiki Activity

Update microservice.md

Browse Source
This commit is contained in:
huangzhhui 2019-05-07 22:21:23 +08:00
parent 0d3e761ee9
commit 33e3b077a6
1 changed files with 4 additions and 4 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

8
zh/microservice.md
View File

@ -24,7 +24,7 @@
### 弹性
实现弹性系统的一个关键概念就是 `舱壁(Bulkhead)`，如果系统中的一个组件或一个服务不可用了，但并没有导致级联故障，那么系统的其它部分还可以正常运行。微服务的 `服务边界` 很显然就是一个 `舱壁(Bulkhead)`，在 `单体架构(Monolithic architecture)` 系统中，也就是传统的 PHP-FPM 架构下的系统中，如果某个部分不可用，那么大部分情况是所有功能都不可用，虽然可以通过负载均衡等技术将系统部署在多个节点上面降低系统完全不可用的概率，但对于 `微服务架构(Microservice)` 系统而言，其架构本身就能够很好地处理服务不可用和功能降级等问题。
实现弹性系统的一个关键概念就是 `舱壁(Bulkhead)`，如果系统中的一个组件或一个服务不可用了，但并没有导致级联故障，那么系统的其它部分还可以正常运行。微服务的 `服务边界` 很显然就是一个 `舱壁(Bulkhead)`，在 `单体架构(Monolithic architecture)` 系统中，也就是传统的 `PHP-FPM` 架构下的系统中，如果某个部分不可用，那么大部分情况是所有功能都不可用，虽然可以通过负载均衡等技术将系统部署在多个节点上面降低系统完全不可用的概率，但对于 `微服务架构(Microservice)` 系统而言，其架构本身就能够很好地处理服务不可用和功能降级等问题。
### 扩展
@ -32,8 +32,8 @@
### 简化部署
在代码量庞大的 `单体架构(Monolithic architecture)` 系统中，即使只修改了一行代码，也需要重新部署整个系统才能够发布该变更，这种部署影响很大、风险很高，因此涉及到的干系人不敢轻易做部署，于是在实际的操作中部署的频率就不变得很低，版本与版本之间会对系统做了很多的功能或 Bugfix，并一次性将大量的变更一次性发布到生产环境中去，但两次发布之间的差异越大，出错的可能性就更大。
当然在传统的 PHP-FPM 架构下的开发中，我们可能不会存在这样的问题，因为热更新是一种天然的存在，但利弊是同时存在的。
在代码量庞大的 `单体架构(Monolithic architecture)` 系统中，即使只修改了一行代码，也需要重新部署整个系统才能够发布该变更，这种部署影响很大、风险很高，因此涉及到的干系人不敢轻易做部署，于是在实际的操作中部署的频率就不变得很低，版本与版本之间会对系统做了很多的功能或 `Bugfix`，并一次性将大量的变更一次性发布到生产环境中去，但两次发布之间的差异越大，出错的可能性就更大。
当然在传统的 `PHP-FPM` 架构下的开发中，我们可能不会存在这样的问题，因为热更新是一种天然的存在，但利弊是同时存在的。
### 与组织架构相匹配
@ -49,7 +49,7 @@
## 没有银弹 No Silver Bullet
虽然 `微服务架构(Microservice)` 好处众多，但 **微服务不是银弹 ！！！** ，您需要面对所有分布式系统都需要面对的复杂性，你可能需要在部署、测试和监控上做很多的工作，在服务间调用、服务的可靠性上做很多工作，甚至您还需要处理类似于 分布式事务 或者与 CAP 相关的问题。在实施 `微服务架构(Microservice)` 之前您的团队必须储备足够的分布式系统相关的知识体系，以面对很多您在 `单体架构(Monolithic architecture)` 下可能没有面临过甚至没有考虑过的问题。
虽然 `微服务架构(Microservice)` 好处众多，但 **微服务不是银弹 ！！！** ，您需要面对所有分布式系统都需要面对的复杂性，你可能需要在部署、测试和监控上做很多的工作，在服务间调用、服务的可靠性上做很多工作，甚至您还需要处理类似于 分布式事务 或者与 CAP 相关的问题。尽管 `Hyperf` 已经为您解决了许多的问题，但在实施 `微服务架构(Microservice)` 之前您的团队必须储备足够的分布式系统相关的知识体系，以面对很多您在 `单体架构(Monolithic architecture)` 下可能没有面临过甚至没有考虑过的问题。
*| 本章节部分内容译自 Sam Newman 的 《Building Microservices 》*