微服务架构已然是互联网领域的主流架构选择，甚至在一些局部地方已经进一步向Service Mesh迈进，但为什么需要微服务，微服务架构究竟解决了什么问题，感觉也没有在哪里看到一个特别好的介绍。于是结合自己一段时间工作下来的感受，梳理一下自己在微服务方向上的一些理解。
微服务抑或单体
在微服务架构（MicoService）兴起之前，是单体架构（Monolithic）时代。单体架构下，产品的所有功能在技术侧以整体进行开发、维护、上线。单体架构本身很容易理解，但是为什么这些年逐渐从单体转变为微服务。是因为技术人员不断造轮子的被动结果，还是微服务真实的满足了产品研发的诉求？但时不时也能看到一些文章介绍某某公司又放弃了微服务退回单体架构，例如Segment, InVision等，这些反面的意见又是因为什么？
核心问题是什么
直接去分析微服务架构的优缺点可能难以解释清楚在架构选择上的理由。最基础的架构选择对应的是研发场景问题的解决，如果能够梳理清楚问题，那么选择怎样的架构可能就是不言自明了。
微服务架构的提出大概在2010年前后，真正开始在互联网逐渐流行大概在2014年左右。这个时间段整个行业大的变化实际就只一个，移动互联网的逐渐拓展覆盖，用户规模的大量增加。这个变化的后果，带来的技术难点就是业务增长。
增长的副产品
业务增长带来的表现有哪些？
产品功能增加
如果越来越多的人来使用产品，不可避免带来的是产品复杂度的增加。为了满足不同用户的诉求，既有功能逐渐丰富，新功能不断添加。特别是国内产品，无一例外渴求着做大做全，因此产品复杂度是不断在非线性增加。
人员规模增加
相同规模的团队是否能够交付越来越多的功能？理想中可能可以，现实中差距太远。当做的事情增加之后，连带着是人员的不得不增加。技术团队的组织规划也逐渐变得复杂。
技术风险增加
越多的功能越多的人，产品线上稳定运行的风险也逐渐增加。局部的错误可能快速扩散，同时也不太能找到那些对全部功能技术都了解的个人。技术失控的风险也愈加明显。
业务流量增加
流量增加是增长最直接的表现，也是最容易理解的。在技术侧，对应不同流量场景的技术方案是会不一样的。高并发场景对应的技术方案复杂度相对而言无疑是更为复杂的。
单体架构的缺陷
如何应对“增长”，架构演进的选择是微服务架构。那为什么不依旧保持单体架构呢？
代码组织问题
在单体架构下产品对应的代码组织基本以单一代码仓库或少量几个代码仓库构成。所有的功能代码都在这些仓库中进行维护。单体架构对应的组织形态应该是中心化的，但人员规模的增长必然导致中心化的单一团队分拆成多个小团队。在这种情况下，如何对代码进行组织就会逐渐复杂。
如何清晰的设计代码结构，让各模块归属在合适的位置让合适的团队进行开发。如何约定研发流程来处理不断出现的代码合并冲突问题。种种这些都是必须要去解决的，但在单体模式下又是极难解决的。
性能效率问题
所有的功能模块都在一起的最直接后果就是代码太臃肿了，不论是编译打包还是启动执行的时间都会大幅度上升。当这种臃肿超出一定界限之后，开发体验与开发效率就会变到让人难以忍受。
故障扩散问题
没有开发人员能够保证不写出bug，功能复杂度与人员规模的增加，实际也会带来bug的增加。在单体架构下，一个非常边缘功能的问题也可能导致整个服务不可用。单体架构在故障隔离上基本无能为力。
协作边界问题
问题容易扩散带来的另外一面就是如何更好的协作。发现问题后谁来跟进，这个最为基本的问题在人员规模大了之后可能都很难清晰，毕竟任何一方都可能是导致问题的关联方。
机器成本问题
不同产品功能的使用量级是不一样的，在单体架构下无法针对局部去进行资源扩容。为了提升局部性能只能整体进行扩容，由此会造成过多的资源浪费，提升成本。
技术瓶颈问题
即便不考虑成本进行了资源扩容，由于底层技术的限制，也会制约扩容的范围。举个例子，比如数据库连接数的限制等。当然通过一定的上层处理也可能绕开此类问题，但付出的代价也不会低。
拆分
如果把微服务架构认为是某种理念的话只用一个词来描述，那最关键的一点会是“拆分”。
拆！
为了应对增长，现实决定让更多的人参与进来，技术架构如果不能匹配人员组织，那么人效就会严重受阻。也就是说在技术架构层面，需要一种能够将产品功能开发分解到不同团队，分别开发，分别部署的架构能力。
将大问题分解成小问题，分治，并行。如何达成这个诉求，是架构需要解决的。
微服务架构
为了应对上述单体架构下的问题，于是就产生了微服务架构。不论是用何种框架实现，微服务架构的核心点就是需要保证易于拆分，同时拆分之后需要易于协作。也就是说良好的微服务架构体系设计需要满足，
- 适应人员组织，易于分工
- 开发效率提升，独立变更，独立发布
- 故障隔离，微服务之间故障不扩散
- 独立优化，弹性可控
这里有个修饰词“良好”，微服务架构提供了架构层面的基本能力，让分拆成为可能。但是想达到好的效果，是需要去合理设计如何分拆，如何组织不同的微服务。这又是一个充满争议的命题。
什么时候不需要微服务
按照本文的思路，哪些场景是不需要引入微服务架构？没有面临“增长”问题时。
微服务架构必然会引入一些额外的复杂性，所以考量关键点就是，单体架构在“增长”场景下的问题解决与微服务架构复杂性的问题解决两者之间的选择问题。没有银弹，两害相权取其轻，如此而已。
总结
为什么需要微服务？个人的理解就是为了应对增长，微服务架构是不得不的选择。不管这个架构叫什么名字用哪种语言框架实现，技术面需要一种能够适应人员组织，易于分治并行的技术架构选型。
从这个维度出发，从单体架构到微服务架构是一个重要变迁，从微服务架构到Service Mesh或是Cloud Native等概念出现则只是微服务架构下的局部技术演进或替换。
微服务架构真正解决的是人员组织协作问题，其它的各项收益都是在解决此项问题为前提或基础之上获得的。当规模不断增加下人员组织协作问题是真正的痛点，所以微服务架构的广泛流行有着现实依据。后续的Service Mesh/Cloud Native等概念所要解决的问题却不再有那么广泛性，所以这些新技术概念的落地周期相对而言会更长，直到它们直面的问题更广泛的出现为止。