单体架构

所谓单体应用就是将所有的业务场景的表示层、业务逻辑层和数据访问层都放在一个工程中，最终经过编译、打包，部署在一台服务器上。

不足：

1.业务越来越复杂：代码可读性、可维护性和可扩展性下降。

2.并发能力有限：随着用户越来越多，程序承受的并发越来越高，单体应用的并发能力有限。

3.测试的难度越来越大：随着业务的扩张，修改或者增加业务会给其它业务带来一定的影响，导致测试难度增加。

解决以上的并发能力有限的问题，可将单体应用集群部署，并增加负载均衡服务器。这种方式改善了系统的性能，但还是存在不足。

1.系统依然是单体，代码可读性和维护性差。

2.持续交付能力差，业务越复杂，代码越多，修改代码和添加代码的时间越长。新人熟悉代码的时间长、成本高。

微服务

概念：引用“微服务”这一名词的发明人Martin Fowler的理解。将单一程序开发成一个微服务，每个微服务运行在自己的进程中，并使用轻量级机制通信，通常是HTTP RESTFUL API。这些服务围绕业务能力来划分架构，并通过完全自动化部署机制来独立部署。这些微服务可以使用不同的编程语言，以及不同的数据存储技术，以保证最低限度的集中式管理。

相对于单体服务，微服务的主要体现以下方面的优势

1.将一个复杂的业务分解成若干小的业务，为每个服务拆成一个服务，将复杂的问题简单化。

2.微服务系统是分布式系统，服务与服务之间没有任何的耦合，具有极强的横向扩展能力。

3.服务之间通过HTTP通信协议来通信，使得微服务可以采用任何得=的开发语言和技术来实现。可以选择最适合自己的开发语言和技术，提高开发效率，降低开发成本。

4.减少了测试和部署的时间。每个服务单独部署，测试时只需要部署修改的那个服务，不用像单体应用一样部署整个应用。

5.微服务在CAP理论中采用的时AP架构，即具有高可用和分区容错的特点。高可用体现在大量的微服务集群，实现了7*24小时不间断的服务。另外，分期容错也使得系统更加的健壮。

凡是都有两面行。微服务也有它的不足。

1.构建复杂度高，需要掌握更多的架构知识和框架知识。

2.分布式事务控制，每个微服务有独立的数据库，在协同操作数据时，保证数据的一致性问题较复杂。

3.服务划分不易，需要依靠团队人员对业务的熟悉程度和理解程度。

4.服务的部署复杂，需要开发人员或运维人员对微服务系统有足够强的控制力。

总结

技术应该是随着业务的发展而发展的。当业务很单一时，单体架构够用的情况下，就应该用单体应用，因为它开发速度快，性价比高。但是随着业务的不断发展，用户量不断增加导致单体应用使用很不爽时，就可以考虑微服务架构的系统。在当今大数据时代，微服务也是发展的趋势，所以微服务技术是很重要的开发技能。在之后的章节一起学习微服务架构框架spring-cloud。