java技术的发展
在java开始流行起来之后，主要服务于企业家应用，例如ERP,CRM等等，这些项目是为企业内部员工使用，我们的思维是怎么用设计模式，如何封装代码。让开发人员关注到业务上去，系统也就那么几十几百号人用。
随着互联网的兴起，原本都是用PHP做的应用，随着互联网应用的业务复杂度，用户体量的增加，越来越不实用。然后开发语言开始转向java。
在2010年左右的盛行S2SH(struts2、spring、hibernate)，随着互联网应用的深入，struts2在互联网部署的时候有严重的安全性问题，hibernate虽然有二级缓存这些设置，但是hql不是原生sql很难优化等问题，技术开始使用springmvc、spring、mybatis。
再随着用户体量的不断增加和业务的复杂程度的提升，淘宝开始使用dubbo的RPC框架，然后发展到springboot和springcloud的出现。我们渐渐的在互联网公司中引入分布式框架，直到分布式技术的渐渐成熟。
因为有需求，技术才不断的发展。技术都是方便业务需求的发展的。
业务复杂度的提高和用户体量的增加需要我们分布式如何应对
随着业务复杂度的提高，我们如果还是把程序维护在一个项目里面，不管是实体类的增加，JVM类加载的问题，性能的问题，项目复杂度的问题，这个时候需要我们对项目的复杂度进行拆解，也就是我们技术中说到的垂直拆分，随着我们在对整个系统进行拆分的时候遇到实际部署中遇到的一些问题，我们总结出DDD领域建模的方法论
随着用户体量的不断增加，我们的并发也在不断的升高。关于用户体量的增加，我们数据库的存储也随着增加，当一张表中数据量过大，我们在查询的时候，就会增加磁盘搜索的时间成本，造成一个查询很长时间出不来。为了不会在同一张表中放置大量的数据，我们需要分表的操作。最开始的时候的分布式，大约在12年13年这样我们都是对数据的主键或者对数据进行hash计算，求模分到不同的表中，但是这种行为代码的侵入性太大，后来出了mycat,但是mycat对求笛卡尔交集还有别的一些问题，在分库情况下求交集上经常遇到问题，后来出了springjdbc，然后慢慢的也流行起来了。这个是我们分表的问题。
那么随着用户体量的增加，大量的访问进入到我们的系统。我们知道数据库去执行sql语句的时候，是通过引擎程序执行的。执行引擎也是有性能瓶颈的，这个时候就需要考虑分表的问题了。
单体服务的问题
-
扩展的问题
单体的服务架构通过前端的负载均衡后部署多个实例进行扩展。如果需要对特定的功能进行扩展，我们只能通过多部署服务进行扩展。这样会造成资源的大量浪费。如果是基于微服务部署只需要对特定的功能进行扩展，其他服务实例不需要扩展，比较灵活。 -
交付时间长
单体的服务在业务变更的时候需要构建和部署整个服务，开发人员需要下载整个应用程序进行修复和测试。而微服务只需要修改微服务的部分并部署对应的服务即可，不会影响其他服务的运行。
-
单体服务应用的复杂性
随着应用的业务功能的扩展，团队也需要不断的扩张，各种复杂的业务会交织在一起，造成项目的臃肿，维护起来会越来越麻烦，最后修复功能的时候牵一发而动全身，系统很难维护。在微服务的架构中，每个服务独立负责自己的业务。每个服务的业务域划分清楚以后，维护起来会清爽很多。 -
代码依赖和团队协作的问题
传统的开发模式，我们划分的团队看起来是独立的但是他们在相互的协作的过程中有严重的代码上依赖的问题，团队中相互依赖造成大量工作上的浪费。微服务架构团队之间彼此独立，独立的团队负责独立的业务，工作明确。包括开发部署和监控。 -
应用服务故障的关联
在一个单体服务，如果在交付过程中，一部分程序出现问题会造成整个服务的不可用 -
陷入某种语言的禁锢
由于单体服务是一个整体的项目，所以使用都是同一种开发语言。随着业务的发展，如果某种语言并不能胜任，则需要整体的重构，造成大量资源的浪费，特别是一些大型系统的整体重构是很大的工作量
