文章目录
在以前大家都是在一个项目进行开发，所有的业务都在一起，全端和后台的代码也在一起，这种开发模式称为单体程序开发。在一个单体程序开发时，每次部署整个服务，都要重新测试程序的所有功能，因为不知道哪些功能发生改动了。所以每次开发结束，都有一次很长的测试并修复bug的阶段。
我这前在一家软件开发公司，开发流程是这样的，项目经理在分析整个需求之后，会设定一个又一个开发节点，这个节点包含着上线时间和需要开发的功能。到了节点时，开发就要停止开发进度，进入封板阶段。这时测试人员会对开发功能进行全面测试，统一反馈bug到bug管理工具，开发人员再统一修复bug，再测试，如此反复直到测试通过上线。上到生产时，也要保证开发，测试，运维三方同时在场，防止一旦上线过程出现问题时，开发紧急修复，测试随后测试。那时感觉上线就像打仗一样，没日没夜，常熬通宵。公司在上线的时候会包下公司周边宾馆的房间，便于大家一直加班。不过开发节点的评估是个主观的，一般都会延时，导致测试时间缩短，到了测试阶段大家一般会加班工作，力保进度。在这个紧急的时候，大家想的只有上线，而代码质量，设计模式通通抛于脑后，写出的代码就像恰好拼接的，粗制滥造的建筑，看起来可以用，但是随便拿点什么，它就倒了，对应于程序而言就是修改一点东西就像是拔萝卜带出泥，根本不可维护，也可以说高耦合。
这种工作模式出来的产品基本是浆糊，代码质量惨不忍睹，程序根本无法扩展，对程序员的身体也是极大摧残，迟早会得上一些不会好的慢性病；对程序员技术的成长也没有半点好处，因为工作都是快速copy，没有技术积累的时间；对人做事风格也是极大的损害，能凑合用就凑合用，老大说是啥就是啥。
PS：这种朝夕相处的工作能培养出一种革命情，而且极容易把团队中的男女凑成一对，那家公司基本在开发期间凑齐了两三对，也许是感情，也许是荷尔蒙吧。
软件工程的实践者们后来提出敏捷开发来解决上面的问题，他们把迭代设的很小，两周一个迭代，一周去测试，这样每次迭代改的功能较少，随时调整开发目标和进度；提出了定期code-review，来保证代码的质量，以免出现导致致命bug的代码；对于开发人员，提出了open-close的设计原则，对扩展开放，但对修改封闭，就是设计要实现如果修改功能，应该是加代码而不是修改代码。强调了程序员的能力增强，素质增强，来保证项目的稳劲增强。当然这也导致了一个问题，代码是增量的，不会减少，会越来越多，直到成为一个硕大无比的项目。
随着互联网行业发展太迅猛，又出现很多问题，公司快速扩展出了许多新的业务，和主业务关系不大，也由不同的部门负责不同的业务，这时要把项目再做成一个，关是沟通协调就是一个很大的工作量；对于一个系统来说，系统的有些模块的并发高，有的模块IO频繁，对于这种性能的问题，而且这些模块的并发量像潮汐一般，有时高有时低，如果只是不断的部署n台服务器的话，太浪费服务器了；对于人来说，专注度是有限的，如果专注很少的几个点，他效率就高，如果关注的东西多了，效率就低，对于一个大项目，里面杂七杂八的东西很多，一个正常人很难全面的了解项目，如果其他人修改错误导致项目不可运行，他可能要花很久才能定位这个问题，极大影响开发效率和心情；项目过大，编译一下就要大几十分钟，改了代码想立刻测试一下不可呢，影响效率；对于技术迭代来说，新技术越来越能提高生产力，而且资料多，bug少，但是要给老项目换新技术框架是一个风险很大的事，一般没人敢这么做，这能等它烂下去；上线部署也是一个大问题，这么多人开发一个大项目，只要有一个人失误出现bug，项目上线进度就会break，就会出现上面案例中不停的测试，开发的过程。
这些问题，就可以使用微服务解决。微服务就是把大项目中的模块拆分成一个个独立部署的服务，服务之间通过远程协议进行调用。因为是一个一个小的服务，程序员就能很清楚的了解服务中的所有内容，他开发，修改的效率会提高；由于模块都拆成了服务，对于高并发的服务，可以只对这些服务增加服务器，这样服务器的资源也得到了最大的利用；每个小组负责自己的服务，也不存在其他组的人提交代码；一个一个服务都是独立的，所以随意使用什么技术框架；对于上线来说，也只用上线修改的服务，如果某个服务存在问题无法上线也不会影响其他服务上线进度，其他服务照常上线。
微服务纵使百般好，也一定存在缺点，没有什么技术只有好处没有坏处的。采用微服务架构的公司，服务会非常多，每次上线部署的工作量很大；日志也是四处分散在各个服务中，这需要采用自动化工具去辅助运维人员；在微服务中，服务节点不可用是随机和偶然的，写代码的思维也要发生变化，要多考虑如果调用失败会产生什么问题，常见的问题有雪崩，事务等。
微服务不是银弹，不能包治百病，如果公司体量不大，业务不多，运维人员实力不够，没有必要上微服务。也许随着云服务器的运维工作越来越简单，可能小公司也能在没有运维的情况上采用微服务。
