回答編集履歴
3
誤字訂正
test
CHANGED
|
@@ -1,4 +1,4 @@
|
|
|
1
|
-
質問者のいう様な非常に大きなバイナリになる製品は単一のプロセスで全ての機能を賄う「モノシ
|
|
1
|
+
質問者のいう様な非常に大きなバイナリになる製品は単一のプロセスで全ての機能を賄う「モノリシック」な設計と言えます。
|
|
2
2
|
|
|
3
3
|
|
|
4
4
|
|
|
@@ -10,19 +10,19 @@
|
|
|
10
10
|
|
|
11
11
|
|
|
12
12
|
|
|
13
|
-
またモノシ
|
|
13
|
+
またモノリシックな製品はアップデートが行いにくくなるので結果として単一バイナリのモノリシックな構成は小さなプロダクト向けだという認識です。（ウインドウズアップデートがいつも数ギガダウンロードでディスク大量書き換えだと大変ですよね）
|
|
14
14
|
|
|
15
15
|
|
|
16
16
|
|
|
17
|
-
巨大な仕組みの場合はおっしゃる通り責任分岐点を見極め、分離したマイクロサービスで構築するのがアップデートも行いやすくなりモノシ
|
|
17
|
+
巨大な仕組みの場合はおっしゃる通り責任分岐点を見極め、分離したマイクロサービスで構築するのがアップデートも行いやすくなりモノリシックのいろんな欠点を回避できます。
|
|
18
18
|
|
|
19
19
|
|
|
20
20
|
|
|
21
|
-
モノシ
|
|
21
|
+
モノリシック製品最大の欠点はとある小さな業務の変更（例えば誤字の訂正）なのに全ての業務を止めて差し替えなければならなくなる点です。
|
|
22
22
|
|
|
23
23
|
|
|
24
24
|
|
|
25
|
-
もちろん運用次第ではそれでも構わないということはあるかもしれませんが、こういうリスクを抱えたまま巨大な仕組みをモノシ
|
|
25
|
+
もちろん運用次第ではそれでも構わないということはあるかもしれませんが、こういうリスクを抱えたまま巨大な仕組みをモノリシックな設計にわざわざ振ることはしないでしょう。
|
|
26
26
|
|
|
27
27
|
|
|
28
28
|
|
2
文言整理
test
CHANGED
|
@@ -38,10 +38,12 @@
|
|
|
38
38
|
|
|
39
39
|
|
|
40
40
|
|
|
41
|
+
- 数ギガに及ぶバイナリはビルド・運用・維持全てに無理が出る
|
|
42
|
+
|
|
41
|
-
- コンテンツとロジックを分けよう
|
|
43
|
+
- まずはコンテンツとロジックを分けよう
|
|
42
44
|
|
|
43
45
|
- Goなら1プロセスサービスで大量の処理を捌けるのはメモリに優しい
|
|
44
46
|
|
|
45
47
|
- 多岐にわたる業務は分離実装の方がメンテしやすい
|
|
46
48
|
|
|
47
|
-
- ある程度大きな仕組みにな
|
|
49
|
+
- ある程度大きな仕組みになる予定ならリバースプロキシやロードバランサーを活用した設計に
|
1
プロセスとスレッドの事を追記
test
CHANGED
|
@@ -26,7 +26,7 @@
|
|
|
26
26
|
|
|
27
27
|
|
|
28
28
|
|
|
29
|
-
Goの場合、1プロセスだけでホストのマルチコア性能を引き出す運用が可能です
|
|
29
|
+
プロセス内のメモリは複数のスレッドから参照可能なのでスレッドごとに冗長なメモリを占有する必要はあまりありませんが、プロセスをまたぐ情報は相互参照をOSにより禁止されているのでほとんどの場合は冗長に持たせることになります。Goの場合、1プロセスだけでホストのマルチコア性能を引き出す運用が可能ですのでその場合、マルチプロセスで性能を稼ぐやり方に比べ冗長なメモリを浪費することが無いのは利点の一つですね。
|
|
30
30
|
|
|
31
31
|
|
|
32
32
|
|