背景
自分布式和微服务的概念和技术逐渐趋于成熟的今天，越来越多的人选择将原来的单体应用迁移的微服务上，甚至是云上，微服务的出现很好的解决了现在单体应用（也叫巨石应用）的弊端，更好的保证了应用的拓展和运维。但是，微服务也不是解决问题的“万能药”,对应具体的应用，我们应该具体对待问题。所以只有更好的了解微应用的优缺点，才能针对的使用微服务来解决问题，更是为了避免盲目使用微服务带来的问题
开发
对于开发来说，可能更加关注迁移微服务后的代码变化。微服务是将应用按照功能尽可能小的划分成多个单体应用，所以一个好的划分算法是非常重要的，既要做到解耦合，又要做到不冗余,就需要对应用有着非常熟练的理解和超前的视野，为以后得应用拓展打好基石
成本
成本问题是开发人员第一个考虑的问题，如果应用迁移至微服务，那么相应的技术成本必然是提高了的，解决微服务之间的服务注册与发现等技术难题就是摆在眼前的问题，选择市面上成熟的开源框架，亦或者是自研框架都是一个耗时耗力的工作，但是是不可避免的。显而易见，如果迁移微服务，开发成本是明显提高的。
扩展
对于单体应用来说，最大的问题就是它的拓展性很差，随着业务的发展，整个应用会变得越来越大，这就导致日后维护，拓展变得非常困难。而将应用拆分成一个个独立运行的微服务模块可以很好的解决这个问题，这也是目前很多应用准备迁移到微服务的一个最主要的原因。在扩展这一方面，可以说微服务完全碾压了传统的单体应用。
拓展的优势不至于纵向拓展业务，包括拓展技术栈，微服务还有一个优点就是不需要限定与某一个技术栈或者某一门语言，任何语言都可以进行微服务的开发，然后通过protubuf、http等方式进行通行,这样技术团队就可以多样性发展，针对不用的业务选用最合适的技术栈和语言，各个开发小组之间互相不关联技术栈。多语言开发既可以帮助团队进行收纳更多样性的人才，也可以帮助团队向新势语言的尝鲜和转变。
在拓展的同时，带来的最常见的问题就是冲突，对于本地单体应用而言，代码之间的冲突是不可避免的，递交代码中需要花费时间不停地解决冲突，给开发人员来了心智负担，但是对于微服务而言，不用的模块可以单独使用独立的仓库提交代码，存在冲突的可能性很小，自然提高了开发效率
测试
对于测试而言，迁移到微服务也确实存在一定的影响，无论是测试方法和测试用例可能都要存在一定的变更，但是相比较开发而言，变动也在可以接受的范围内。
单测
单测试针对代码而言的，代码的变动，导致单测也必然发生变化，但是微服务中是模块的改动，部分情况下，某个函数的功能并没有变化，所以对单测的改动可能是比较小的
集成测试
虽然对单测比较友好，但是对于集成测试并没有那么友好了，集成测试是建立在单测基础上的，而微服务改动的逻辑就是以单元测试为基础的独立模块，也就说，集成测试的对象会发生比较大的变化，随着微服务的拆分，各个模块之间的依赖也会越来越复杂，这就会下面问题的出现
- 首先就是测试成本的提升，为了验证多个服务协作后的功能是否正确，就需要为每个微服务搭建相应的基础设施（包括语言环境、数据库等），并且执行部署等步骤
- 其次就是测试的结果存在不稳定性。微服务是建立在分布式系统基础上的，服务之间的通信受到网络延迟、超时、带宽等因素影响的，导致结果存在一定的不稳定性
运维
我个人觉得对于运维，是升级微服务后影响最大的点了。微服务本身也就从改变部署方式的方法来解决巨石应用的问题，自然在部署这一方面颠覆了传统的方式。可能之前一个环境只需要一个容器，或者一个包（即使这个包的打包过程会很长）就可以解决整个环境，但是现在不同了，微服务本身无论大小就需要很多个包或者容器，各个包之间相互通信，协作，才可以维护整个应用的发展。
部署
部署的问题其实大家都比较了解了，切换微服务后，部署就成了一个最大的问题。由于微服务的理念就是将应用按照功能划分成最小的单位，这也就导致单位的数量会很多，同时各个单位之间是解耦合的，所以各个单位之间肯定是需要独立部署的。这就给运维的部署带了很大的挑战，不仅要将多个单位正确部署环境，数据库等，还需要解决各个单位之间通信的问题。
同时多个包之间的管理也是一个巨大的挑战，也许之前的可能就是一个包走天下，但是现在确实多个包一起走。这也就要求运维人员熟练使用自动部署和持续集成的工具，同时这一套流程要完全结合微服务，这样才能在一定程度上解决这个部署的问题
发布
把系统分为多个协作组件后会产生新的接口，这就意味着简单的功能变化就需要改变许多组件，并且需要协调后一起发布，在实际中，一个新的组件发布可能需要同时发布大量的服务来和这个组件通信，这也就导致微服务的发布风险变高。
运营
运营的成本会一般都是随着服务数量的增加而增加。对于微服务而言，其组件的数量是非常多的，这就导致加上构建、运营、监控等进程是组件的3-4倍。如果微服务结合云上部署，对云的需求也就会变多，运营的成本也会增加。
在运营中，对服务的监控是一个非常重要的手段，可以即使发现问题从而避免线上事故的发生，而原来的单体应用只需要关注一个监控页面就好了，但是切换成微服务之后，需要监控的页面可能就是十几个，同时隐藏的问题就更难被发现。一旦出现事故，排查日志也是一个极其困难的问题，至少需要做好链路追踪的功能。
综上所述，将应用升级成微服务并不是一个简单的事情，在你将应用升级成微服务之前，我觉得你应该考虑更多的问题，考虑自己的应用是否有必要上微服务，是否能够解决升级微服务后带来的问题。其实我的公司目前的应用也是非常庞大的，但是公司目前使用的还是分布式架构来优化问题，并没有升级微服务，也许有的时候你并不需要微服务！
