单体应用架构存在的问题
- 一个 war 包含所有功能的应用程序，通常称为单体应用。尽管在程序中进行了模块化，但若干业务模块被打包在一个 war 包中，这样的应用系统称为单体应用。
- 优点：容易部署、测试。可以快速实现需求。
- 缺点：随着需求的不断增加，开发团队的状大，代码库也在迅速增长， 此时单体应用变得越来越臃肿，可维护性、灵活性逐渐下降，维护成本高：
- 模块非常多、模块的边界模糊、依赖关系不清晰、每次修改代码心惊胆战，甚至增加一个简单功能或修改一个 bug 都会带来隐含的缺陷。
- 随着代码的增多，构建和部署的时间也会增加，在单体应用中，每次功能的变更或修改 bug 都会导致重新部署整个应用。全量部署耗时长、影响范围大。
- 可靠性差，某个 bug 可能 OOM ，最终导致整个应用崩溃。
- 扩展受限，无法根据业务模块的需要进行伸缩部署。如：有的模块是计算密集型的，需要更强劲的 CPU ；有的模块是 IO 密集型的，需要更大的内存。
- 技术创新受阻，单体应用往往使用统一的技术平台或方案解决所有的问题。
单体应用架构问题的解决方案
将一个单体应用开发为一组小型服务的方法，每个服务运行在自己的进程中，服务间通信采用轻量级别通信机制。这些服务围绕各自的业务能力构建并通过全自动机制独立部署。每个服务可用不同的语言开发，使用不同的数据存储技术。
微服务的优点与挑战
优点
- 每个微服务可独立运行在自己的进程里，单个微服务代码量较少，所以启动会较快。
- 局部修改容易部署，单体应用只要有修改，就得重启整个应用，微服务进行修改，只需要重新部署这个服务即可。
- 一系列独立运行的微服务共同构建整个系统。
- 每个微服务为独立的业务开发，一个微服务只关注某个特定的功能，所以业务清晰、代码量较少。如订单管理、用户管理等。
- 微服务间通过一些轻量的通信机制进行通信，如 RESTful API。
- 结合项目业务及团队特点，合理地选择技术栈，可以使用不同的语言与数据存储技术。
- 按需要伸缩，可根据需求，实现细粒度的扩展，如某个微服务遇到瓶颈，可以结合这个微服务业务特点，增加内存、升级 CPU 或增加节点。
总之，单体应用架构的缺点，恰好是微服务的优点，但不是完美的解决方案，微服务同样有很多挑战。
挑战
- 在微服务中，需要保证几十甚至上百个服务的正常运行与协作，给运维带来很大的挑战。单体架构时代，只需要保证一个应用正常运行就行，而在微服务中，需要保证很多个服务正常运行与协作，是一个很大的挑战。
- 使用微服务构建的是分布式系统，对于一个分布式系统，系统容错、网络延迟、分布式事务等都会带来巨大的挑战。
- 微服务间通过接口进行通信，如果修改某个微服务的 API ，可能所有使用该接口的微服务都需要做调整。
- 很多服务可能会使用到相同的功能，而这个功能没有达到分解为一个微服务的程度，可能各个服务都会开发这一功能，从而导致代码重复。尽管可以使用共享库（通过封装成公共组件），但共享库在多语言环境下就不一定行了。
微服务的设计原则
- 单一职责原则，指一个单元（类、方法或服务等）只关注整个系统功能中单独、有界限的一部分，可以帮助我们更优雅地开发、更敏捷地交付。
- 服务自治原则，指每个微服务应具备独立的业务能力、依赖与运行环境。在微服务架构中，服务是独立的业务单元，与其他服务高度解偶。从开发、测试、构建、部署，都可以独立运行，而不应该依赖其他服务。
- 微服务间应该通过轻量级别的通信机制进行交互。跨语言、跨平台。微服务中常用的协议有 REST、 AMQP 等。
