1.应用开发简单
2.易于对应用程序进行大规模的更改
3.测试相对简单直观
4.部署简单明了
5.横向扩展容易

单体架构的坏处

1.过度的复杂度

  系统本身过于庞大和复杂，以至于任何一个开发者都很难以理解它的全部。

  这种极度的复杂度会形成恶性循环，由于代码难以理解，因此开发人员更改更容易出错，每一次更改系统更复杂，更难懂。

2.开发速度缓慢

  因为应用太大，每启动一次都需要很长的时间，因此从编辑到构建、运行再到测试这个周期花费的时间越来越长。

3.代码部署的周期很长，而且容易出问题

  程序更改部署到生产环境的时间变得更长.

  代码库复杂，以至于一个更改可能引起的影响是未知的。

  开发团队分为多个小组，当需要发布的时候漫长的合并和测试时间非常长。

4.难以扩展

  不能做到按需扩展，只能是扩展整个系统。

5.交付可靠的单体应用是一项挑战

  单体程序缺乏可靠性，这个问题导致了频繁的系统故障和宕机。

  应用程序缺乏故障隔离，因为所有模块都运行在同一个进程当中

6.需要长期以来某一个可能已经过时的技术栈

  团队长期使用一套相同的技术，单体架构使得采用新的框架和编程语言变的及其困难。

微服务架构

1.x轴: 多个相通实例之间实现请求的负载均衡
2.Y轴: 根据功能将应用程序拆分成服务
3.Z轴: 根据请求的属性路由请求

X轴:多个相通实例之间实现请求的负载均衡

  在负载均衡器之后运行应用程序的多个实例，负载均衡器在N个相同的实例之间分配请求，这是提高应用程序吞吐量和可用性的好方法.

Z轴: 根据请求的属性路由请求

  不同于X轴，Z轴根据请求当中的某一个条件来路由请求。下面例子中每个应用程序负责一部分id的用户。对于应用程序需要处理增加的事务和数据量时，Z轴扩展是一种很好的扩展方式.

Y轴: 根据功能将应用程序拆分成服务

  X轴和Z轴扩展有效地提升了应用程序的吞吐量和可用性，然而这两种方式都没有解决日益增长的开发问题和应用复杂性。所以我们需要采用Y轴扩展,也就是功能分解，把一个单体应用分成一组服务。




微服务定义:把应用程序功能性分解为一组服务的架构风格