前言
微服务在编程圈火的是不行不行的啦，可能还有很多小伙伴还没有进行微服务实操，但这个词，要说没听过、没看过，那小伙伴一定是假Programmer。
虽然微服务很火，但不能盲目使用；先不说涉及技术和工具有多少，首先应该针对业务需求和开发团队有一个规划，评估业务需求的复杂度和开发团队人数及技术能力。对于微服务本身，业务的划分、开发的技能、部署的方案、维护的成本每一项都不能缺，否则很大一种可能就是以失败告终。
来，小伙伴们一起聊聊，我先来说说我的理解，小伙伴可以评论，私聊都行.....
正文
微服务的出现，并不是为了替代原先单体架构，而是为了解决单体架构出现的相关问题；也不是为了取代面向SOA服务化的设计，其实应用场景很关键，通常SOA面向服务化的方式，是企业信息化整合的常用的手段；对于SOA，虽然也是面向接口通讯，但我的理解其实是将更多的单体程序整合，业务细分没有微服务那么精细。所以微服务并不是为了取代某一种程序架构，而是它更适合于某种业务场景或更好地解决某种问题。
单体到微服务的演变
对于单体架构而言，本身就是一种高生产力的架构，程序员上来就干，干完就上线。尽管随着业务复杂和访问量的增多，也可以通过分布式+集群的方式实现应用程序在高并发下的高可用；但是在Code过程中，当每新出一种方案解决遗留问题时，随之而来也有新问题的诞生，只是利益大于危害罢了。接下来，看看单体是如何演变到微服的，下图只是针对软件架构进行演变描述，图片为自顶向下逻辑查阅。
从上图看到，从最初的一台服务器，随着业务需求复杂及并发数据的增大，演变到三台服务器，应用程序、缓存、数据库各自有专门的服务器的处理；通过缓存中间件缓解数据库压力，从而可以接受更多的请求，但是单台应用服务器的内存、CPU处理能力、文件IO、网络IO都有瓶颈，当业务需求增加、并发量增大时，就要考虑集群啦。咱们接着聊↓↓↓
上图为了应对高并发实现高可用，刚开始采取了集群部署的方式，将请求合理分配到各个集群服务器中，提升处理能力。这样一来，随着长时间数据的积累，特别针对数据比较多的系统，就会导致单库或单表的数据量比较大，最终影响系统性能；这里一般的解决方案会采用分库分表的形式解决，数据量特别大的，可以集合大数据平台进行数据保存和分析，这里就不在单独作图表示啦；
当一个系统到了集群部署这一步，这个项目也不算小啦；通常业务需求会陆陆续续而来，最终会导致单体代码量增大，维护和添加功能不容易，而最好的办法是将比较单独的业务独立成一个项目，通过分布式的方式实现新增需求的扩展，项目之间通常使用API、RPC或消息队列的方式进行通信；分布式+集群其实已经足够能应付项目的开发啦，究竟存在哪些问题促使微服务的到来呢？
单体架构面临的问题：
-
部署成本高：只要稍微改一处代码，就可能导致整体替换部署；一些项目，时间就是金钱，不能接受；
-
迭代速度慢：项目整体庞大，稍一改动，就得需要花费大量的时间整体测试验证；
-
不易于扩展：当扩展需求时，只能持续往项目中增加代码，最后导致开发难度系数增大，风险高；部署扩展也有风险；
-
大量代码重用：虽然已经分布式，但独立出来的项目还是单体，存在大量代码重用，比如权限和一些公共功能模块等；
-
新人上手成本高：需要整体了解项目逻辑，花费更多的时间，否则容易出错，风险高；
单体架构的问题作为导火索，再加上当今业务需求的复杂化及迭代速度要求高，最终就促进了微服务的落地，为什么是落地呢？其实微服务概念在2014年一位马丁.福勒的工程师就提出啦。
微服务这张图去掉网关和服务治理是不是和分布式有异曲同工之处，其实微服务就是分布式，不过其划分的更加精细，当然对于监控和追踪那些没在图中体现，那微服务能解决什么问题呢？
微服务解决哪些问题(最接近开发的点)
-
部署成本低：针对具体的服务模块进行部署即可，不影响整体系统其它服务模块运行；
-
迭代速度快：单独模块服务易于开发和维护，负责人员能快速进行开发、验证；
-
伸缩性好：开发可以根据业务进行服务划分，快速开发，不影响其他服务；部署易于扩展；
-
代码重用好：对于公共服务模块进行独立共用，比如用户认证，权限管理等相关公用模块； 电商里面的支付、物流等；
-
新人上手成本低：针对进入项目的新人，可以先从单个服务开始进行开发，更容易上手，风险低；
是不是把单体对应的问题都解决了，最起码好处很明显；当然还有其他优点，比如开发不限于语言，可以多语言进行开发等；
对于每一种方案，解决问题的同时，肯定也有新问题的产生；绝对完美对于编程而言，好像这样的方案还没有，但相对完美还是得追求的，微服务究竟带来哪些问题呢？
微服务带来的问题(最接近开发的点)
-
分布式问题更加复杂化：因为本来分布式问题就存在，比如分布式锁，分布式事务，数据一致性等问题，随着服务的细化，自然就让分布式问题更加复杂化；
-
问题排查增加难度：微服务很多时，如果出现问题，需要明确的定位，比起单体定位问题更加难啦，但可以借助追踪工具和日志分析工具进行辅助；
-
整体项目质量管控更难：从性能方面，多服务交互需消耗网络IO；单个服务挂了，如果处理不好可能导致系统雪崩；一般需要做熔断、隔离、限流等相关防护；
-
对应开发人员技术要求高：不仅是业务开发，对业务划分、服务之间通讯、服务部署、服务监控、虚拟化等都得有所熟悉，所以从技术开发到运维监控都得有对应的技术栈知识的支撑；
-
部署难度增加：当服务很多时，靠人为进行操作已经不现实；
所以，微服务并不是完美，只是在解决问题上带来的好处相对比带来问题更有价值；
既然最终都要演变到微服务，直接用是不是最好？
一般情况，各路大神都不建议直接使用微服务架构，而是根据业务驱动架构的演进，通常在使用微服务时，需要考虑以下情况：
-
项目生产力要求，其实就是商务，如果公司允许有足够的时间进行开发，可以继续考虑；否则单体架构前期的生产力更容易体现；
-
业务复杂度要求，如果业务需求本身不复杂，后续新增可能性不大，没必要为了流行使用微服务；
-
开发团队要求，微服务初期是需要花费大量的人力的，后期运维也是重要活，如果团队人不多、技术不熟，得综合考虑，否则会累死；
说这么多，不是说使用微服务不好，而是过早的使用，反而会一团糟；还是那句话，一个项目在开发过程中过早的过度优化，肯定等于玩火自焚：项目周期可能不能如期完成；当前的优化可能并不是适合后面的开发，可能还会重工等。
在刷博客的时候，看到一个词：单体微服务，当然这不是官方的词，是博友自己的理解，就是用微服务的思想设计单体程序，这样后续过渡到微服务的时候就相对平滑；
有没有小伙伴关注到图片上针对每一次演变都标有段位，从倔强青铜到至尊星耀，那为什么没有最强王者？或者说微服务为什么不是最强王者呢？ 软件架构随着业务驱动会不断发展，总有一些新思路会出现，如今现在有些大厂在搞的Service Mesh(服务网格)可能就是下一个微服务演变的架构，所以给最强王者留了个问号。
总结
微服务对于复杂业务的确很香，但同时也带来了相关问题，同时要求的技术栈比较丰富，所以说它是麻辣味的，并不是一开始就能将其一下消化，需要慢慢实践。好啦，微服务我理解的差不多是这样，小伙伴欢迎指点及分享自己的想法，互相学习；
接下来会针对微服务的落地持续学习和分享相关文章，具体计划在下一篇再好好说说。
一个被程序搞丑的帅小伙，关注"Code综艺圈"，跟我一起学~
