微服务前期：单体架构不足之处

在软件设计中，经常提及和使用的经典的3层模型：
即表示层、业务逻辑层和数据访问层

典型的单体应用就是讲所有的业务场景的表示层、业务逻辑层和数据访问层放在同一个工程中，最终经过编译、打包，部署在一台服务器上。
例如经典的J2EE工程，它是将表示层的JSP，业务逻辑层的Service、Controller和数据访问层的Dao，打成war包，部署在Tomcat或jetty或其他Servlet容器中运行。

单体架构优点：

性价比非常高、开发速度快、快发成本低（只需要一台廉价的服务器）

单体架构不足：

1、当业务越来越复杂，单体应用的代码量越来越大，代码可读性、可维护性下降，新人接手代码所需的时间成倍增加，业务扩展带来的代价越来越大
2、随着用户越来越多，程序程序的并发越来越高，单体应用的并发能力有限。
3、测试的难度越来越大，单体应用的业务都在同一个程序中，随着业务的扩张、复杂度的增加，单体应用修改业务或者增加业务可能会给其他业务带来一定的影响，导致测试难度增加

单体架构处理并发

随着业务的发展，大多数公司会将单体应用进行集群部署，并增加负载均衡服务器（例如Nginx等）。
另外，还需要增加集群部署的缓存服务器和文件服务器，并将数据库读写分离

这种架构有一定的处理高并发的能力，也能应对一定复杂的业务需求，改善了系统的性能，但是依然没有改变系统为单体架构的事实，此时存在的不足之处如下：

1、系统仍然为单体应用，大量的业务必然会有大量的代码，代码的可读性和可维护性依然很差。
2、面对海量的用户，数据库将会成为瓶颈，解决方案将使用分布式数据库，就是将数据库进行分库分表。
3、持续交付能力差，业务越复杂，代码越多，修改代码和添加代码所需的时间越长。新人熟悉代码的时间长，成本高

简说微服务好处：

例 A、B、C三个服务
1、不同的服务可以部署在同一台服务器，类似单体服务
2、扩展，不同的服务部署在不同的服务器
3、如果A服务请求量特别大（如双11订单服务），那么A服务可以单独进行集群部署（将A服务部署多台服务器）

纯属个人记录，请勿参考