From 457425b785a748789f9cd63475d9802084be01d6 Mon Sep 17 00:00:00 2001 From: WangBoguo Date: Mon, 30 Jan 2017 18:14:08 +0800 Subject: [PATCH 1/2] =?UTF-8?q?=E5=8E=9F=E6=96=87people=20can=20call=20ove?= =?UTF-8?q?r=20HTTP=20=E8=BF=99=E9=87=8Ccall=E7=BF=BB=E8=AF=91=E6=88=90?= =?UTF-8?q?=E8=B0=83=E7=94=A8=E6=84=9F=E8=A7=89=E6=AF=94=E8=BE=83=E5=A5=BD?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index 79dcf8f..c2cbea1 100644 --- a/README.md +++ b/README.md @@ -235,7 +235,7 @@ Rails 可以在很多场景下使用，但最初是用来做整合系统的 [Maj 系统开发的复杂度多半是引入了系统组件之间的界限，比如现在 A 组件该如何和 B 组件进行相互调用。本地组件之间的方法调用要远比 Microservices 之间的远程调用来得简单。Microservices 是另一个存在失败状态、延长问题，依赖更新周期的新场景（需要对比原文理顺，有点不太对），有许多潜在的问题等着尝试拆分的人去冒险。 -当然有时候这种服务的拆分是必要的。若想建立让大家可以透过 HTTP 实用的 API，好吧，那你就得毫无怨言的处理许多的问题（虽然处理进来的请求比发出去请求要单一，但要是你的服务挂了，别人就会收到错误的状态了）。但这至少对你个人的开发体验伤害有限。 +当然有时候这种服务的拆分是必要的。若想建立让大家可以透过 HTTP 调用的 API，好吧，那你就得毫无怨言的处理许多的问题（虽然处理进来的请求比发出去请求要单一，但要是你的服务挂了，别人就会收到错误的状态了）。但这至少对你个人的开发体验伤害有限。 更糟糕的是，当系统过早解耦，或是过早拆成小服务，以及更糟糕地拆成 Microservices。这是现代网络应用的错误认知，你只会反复地重造系统：同样的功能在后端做一次，在前端再做一次，在 Native 手机端又再次实现一次等等。这不是自然规律，你也不需要这样。 From 3b80b60d3445085fc5d8c9cd83c607f9ab9812f3 Mon Sep 17 00:00:00 2001 From: WangBoguo Date: Mon, 30 Jan 2017 18:36:00 +0800 Subject: [PATCH 2/2] =?UTF-8?q?=E6=84=9F=E8=A7=89=E8=BF=99=E5=8F=A5?= =?UTF-8?q?=E8=AF=9D=E7=9A=84=E7=BF=BB=E8=AF=91=E5=92=8C=E5=8E=9F=E6=96=87?= =?UTF-8?q?=E6=9C=89=E7=82=B9=E4=B8=8D=E7=AC=A6?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index c2cbea1..8e46ca2 100644 --- a/README.md +++ b/README.md @@ -237,7 +237,7 @@ Rails 可以在很多场景下使用，但最初是用来做整合系统的 [Maj 当然有时候这种服务的拆分是必要的。若想建立让大家可以透过 HTTP 调用的 API，好吧，那你就得毫无怨言的处理许多的问题（虽然处理进来的请求比发出去请求要单一，但要是你的服务挂了，别人就会收到错误的状态了）。但这至少对你个人的开发体验伤害有限。 -更糟糕的是，当系统过早解耦，或是过早拆成小服务，以及更糟糕地拆成 Microservices。这是现代网络应用的错误认知，你只会反复地重造系统：同样的功能在后端做一次，在前端再做一次，在 Native 手机端又再次实现一次等等。这不是自然规律，你也不需要这样。 +更糟糕的是，当系统过早解耦，或是过早拆成小服务，以及更糟糕地拆成 Microservices的时候。这种行为通常起源于一个错误的观念，即如果你想做一个现代网络应用，你需要做的只是反复地重造系统：同样的功能在后端做一次，在前端再做一次，在 Native 手机端又再次实现一次等等。这不是自然规律，你也不需要这样。 若想在整个应用里共享大部分的功能，这完全是可行的。桌面应用和 Mobile App 可以用同样的 Controller 和 View。尽可能地把功能集中在 Majestic Monolith - 整合系统。集中在一起完全不需要牺牲构建速度，开发者体验，以及其它错让你以为要尽早拆分系统的因素。