monolithic_or_microservices

关于微服务和单体服务的讨论

单体保卫战（第一部分）

v2ex讨论

你以为是微服务或Docker？其实是组织架构！

跟大佬的文章比我这篇算是读书笔记.

总结, 面试的时候问你微服务有什么好处呀你可以这么说(而且只可以这么说)

1. 稳定性好，故障隔离, A 服务崩溃只会影响自己，一般不会导致整个应用崩溃

2. 部署隔离，避免改个小 bug 要重启整个巨型应用

3. 伸缩性好: 还有给横向伸缩的提供便利. 可以只扩展瓶颈, 而不是整个单体

4. 技术方案更自由，A 服务可以用一种框架写，B 服务又可以用另一种框架写，甚至引入其他编程语言. 自己想引入什么就引入什么不用担心破坏其他模块.每个微服务可以选择适合自己的持久化技术

5. 开发效率比较高, 又因为每一部分都变成轻量级, 所以更好修好开发.包括启动速度快.

6. 职责拆分，便于团队横向扩展

7. ---

8. 随着时间推移, 单体系统层间渗透会变得普遍.微服务增加了渗透成本

9. 可以把不是很重要的服务部署在比较便宜的硬件上, 高可用解决方案变得不那么昂贵了

缺点:

• 运维要求比较高
• 分布式的复杂度更高, 因为网络环境复杂, 会面对更大的延迟, 事务管理也很难.
• 通信成本高
• 重复劳动.

摘录定基调

1. 单体架构和微服务架构都有其存在的道理，不过单体应用

2. 必须进行模块化才能得以持续发展.

3. 也很需要平台为其提供支持.

4. 要求定义好模块的边界、接口和职责。（先构建模块化的应用，在将来可以拆分成微服务）

5. 我所说的单体并不是指那种堆砌了大量代码的单体应用，而是指由多个模块组成的应用。

6. 采用微服务架构意味着要放弃事务和模块（服务）间的引用完整性。实现微服务需要付出更大的成本。

7. 单体和微服务之间有一个关键的区别，对于模块职责的变更，单体比微服务具有更高的宽容度。如果不了解一个领域的具体知识或者领域太复杂那就很难定义好一个微服务.

8. 如果一个服务（我们把它叫作消费者服务）需要使用其他服务（数据所有者）的数据

• 消费者服务可以向数据所有者索要数据，

• 或者将数据复制一份给消费者服务.不过这两种方式都有其缺点。

  对于前一种来说，服务间存在临时的耦合关系（数据所有者必须处于可用状态），而后一种需要额外的精力和基础设施才能实现

5. 集中数据

• 优点 集中数据还简化了批处理，在这些需要用到批处理的地方，出于对效率的考虑，我们将业务功能（比如存储过程）和数据部署在一起。集中数据还能简化一些运维任务，比如数据库备份和数据库完整性检查。有助于事务管理.
• 缺点 集中数据很容易在 RDBMS 中形成一个"大泥球"。我们一不小心就会创建出很多外键（也就是结构化耦合），我们还要面对一些风险，比如开发人员直接通过 SELECT 进行跨模块查询（也就是行为耦合）

6. sdf