单体架构到分布式应用
单体架构与分布式应用特性对比
微服务的优势与缺陷
人月神话一书中提及，没有银弹，意思是只靠一把锤子是盖不起摩天大楼的，要根据业务场景选择设计思路和实现工具。当我们在构建现实中的微服务系统中，其面临的问题又可以细化为服务拆分与服务治理等不同的考虑维度，微服务并不等同于我们选择了
当我们以这种方式考虑微服务时，我们可能会质疑为什么我们会完全采用微服务架构。答案通常是独立部署和扩展。对于大型的整体应用程序，组织不得不一次部署或释放所有代码。应用程序的每个新版本都可能涉及许多更改。部署变得既危险又费时。任何人都可以使整个系统瘫痪。换句话说，组织为了获得运营利益而采用微服务，而以性能为代价。组织还必须承担维护支持微服务所需的基础架构的成本。事实证明，在许多情况下，这种折衷是有道理的，但它也强烈反对过早采用微服务架构。
微服务的优势可以如下所述：
- 每个服务足够内聚，足够小，代码容易理解、开发效率提高；
- 服务之间可以独立部署，微服务架构让持续部署成为可能；
- 每个服务可以各自进行
x 扩展和z 扩展，而且，每个服务可以根据自己的需要部署到合适的硬件服务器上； - 容易扩大开发团队，可以针对每个服务（Service）组建开发团队；
- 提高容错性（Fault Isolation
） ，一个服务的内存泄露并不会让整个系统瘫痪； - 系统不会被长期限制在某个技术栈上；
系统的可靠性。在微服务架构中，整体系统的可靠性上升。单个服务可以在不影响整个系统的情况下宕机（并被回滚
） 。 关注点的分离。从架构上来看，微服务架构迫使你去问 “这个服务为什么存在？ “更加清晰地定义不同组件的角色。 明确所有权。代码拥有者变得更加清楚。服务通常由个人、团队或组织级别拥有，从而实现更快的增长。 自主执行。独立的部署 更清晰的所属权限，让不同的产品和平台团队能够自主执行。 开发人员的速度。应用团队可以独立部署他们的代码，这使得他们能够按照自己的项目进度来执行。
但是，随着公司规模的扩大（从
其典型的缺点可以如下所示：
- 开发与运维复杂度的增加：开发人员要设计服务之间的通信机制，对于需要多个后端服务的业务场景，要在没有分布式事务的情况下实现代码非常困难；涉及多个服务直接的自动化测试也具备相当的挑战性；
- 真实系统往往难以明确划分边界：在生产环境中要管理多个不同的服务的实例，这意味着开发团队需要全局统筹；
- 状态管理与通信的复杂度；
- 分布式事务与版本管理；
由于服务之间的调用可能会深入很多层，因此了解服务之间的依赖性可能会变得非常困难。第