在写架构的时候，就要想着，哪些功能是要以后可能要单独部署的，虽然一开始写的时候可以写在一个解决方案里，但那些请求的dto，和返回的视图，业务依赖，能随时独立出去，完全不需要做任何操作，即使是文件夹复制移动都不需要，就能够把该功能独立成一个解决方案，做到独立部署，然后通过远程接口的方法调用处理独立部署的业务；我认为这是微服务架构的最主要的作用。当业务多起来了，数据量大了，用微服务架构开发的应用，可以很快的把一个数据库拆分成不同的数据库，分服务器部署，实现突破业务瓶颈；
其实我理解的微服务，就是把以前一个接口一个数据库里实现的逻辑，改变为通过一级或多级远程调用去不同的服务器和数据库获取数据，然后完成整个逻辑。这也算是分布式开发技术了，每次业务要保证在多级远程调用过程中，数据的一致性，在存储数据时，因为是分不同数据库，不同服务器保存数据，有可能一个请求，要保存或更新a、b、c三个不同地区里不同服务器的数据库。就需要保证分布式数据保存的acid：原子性、一致性、隔离性、持久性。
虽然，我在工作中，没有太深入的接触这方面的内容，但感觉得出，这些微服务，分布式技术，只是有这个需求才产生的，以前分布式不火，因为那时候一个数据库curd就没有超过性能瓶颈，而且网络条件也不太发达，使用网络的用户也不多，现在，网络发达了，网民多了，产生的数据就变多了，对于一些企业，一个数据库就有性能瓶颈了，所以就需要分库开发，感觉分库就和微服务是十分匹配的。那些数据多的企业就需要使用这种技术，而那些业务量小的企业，而且数据量一直很稳定，或者并不是直接靠网络数据生存的企业，比如一些把计算机编程技术作为辅助的，其核心是生产制造一些电子产品、工业产品、应用食品的企业，这些企业中的中小型个体或集团其实可能不需要用到微服务架构吧，就不必花大功夫去想处理什么接口幂等、分布式事务这些分布式架构的缺点吧。
我感觉吧，任何事物，都是要随其自然，技术的更新迭代大多也是在于有现实的痛点或瓶颈的倒逼；不断解决这些瓶颈问题，就是在创新，就是在进步；人也一样，有的人有瓶颈了就成为他们的上限了，有的人就能解决瓶颈，实现进步。
