两种架构的比较
大家好，我是老今天跟大家分享一个特别有意思的话题，叫微服务架构。听起来是个技术问题，但是认真的深入的分析之后，发现它不仅是个技术问题，它还涉及到团队的组织架构等等好多因素，项目的特征啥的，咱今天就来聊聊微服务架构。为什么聊这个？其实我们在微服务上踩了一些坑，去年我们接手了一个项目，那个项目号称采用微服务架构，实际上是他们在从单体服务架构向微服务架构迁移的过程中，后来有些问题我们就接手这个项目了，然后他那个项目就相当于做了一半，很多都是微服务的状态，也有一些还处在单体服务，然后我们接手之后就发现我们那个时候不懂，这实事求是，我也不懂什么叫微服务，在此之前听说过，比如说我们的 Cpu里边有微指令，操作系统有微服务架构，但是怎么回事怎么弄，接触得非常好，只非常少，只是就大体上知道一个大体的思路而已。
然后去年一接手这个项目很茫然，哪些也都不知道怎么回事，然后最重要的是这些系统被集成到一起之后出现了很多问题，主要是性能上的问题，开发的效率其实也不高，然后我们就怀疑微服务大家都说这么好，怎么会有这么多问题，陆陆续续的干了几个月，开始就了解了那个系统，也慢慢开始接触了一些微服务方面的思想，后来发现原来这里边原来这套系统里头，离着一个真正的微服务架构差距还是挺大的。
今年疫情的时候时间比较充裕了，没什么事儿我就翻书，看了点视频，学习的系统的学习了一下为服务的这些知识，当然了我这都是蜻蜓点水，我也没有实际的操作的经验，都是靠着过去的经验来理解这些事儿。
有些理解之后就发现其实微服务这个事儿真的不简单，值得聊聊，值得分享一下。
先给大家说说什么是微服务，微服务一般来讲对于咱们传统的所谓单体服务，这是一种软件的架构，以这怎么说？
相对于单体架构，另外一种架构，这个软件架构，怎么讲这个事，咱就说点直白的，我觉得大家真正的架构师肯定少说到这儿肯定很多人就不理解这架构是怎么回事，咱就说你写一程序，通常你写些程序你是建一个项目，对吧？你可能好几个客户端你就建几个项目，在一个客户端里边你会建多个项目吗？通常不会。
也有一些情况比较复杂的系统，我们会建多个项目，实际上这一个项目就相当于是我们把这个软件的这些功能，整体上组织成为一个单体的这么一套东西。
软件的架构就叫单体架构，单体架构也有很多种，提供各种框架了，你像咱们用P2P开发的时候， Tp框架其实就是一种基础的架构，然后在此基础之上再用各种设计模式怎么实现，那也是对架构的完善延伸调整都是这样的。
那么总的来讲，我们这一个项目就用我们这开发的一个产品一个啥的，就这一套这就叫单体架构。
微服务是什么？微服务是我要写很多个项目，我把我要写的软件的功能做分割之后，一些基础的功能要作为一个的小项目来管，把他们服务化。
每一个小的功能，比如说用户管理，关于用户这一块的操作，我做成一个小的服务，比如和微信打交道的那些程序，我就把他们集中到一块，做成一个微信的服务，还有其他的等等这些服务都作为基础的小小模块，相互调用来实现共同完成复杂的功能。
我做一个高层次的服务的时候，比如说我要做一个员工的管理，通常我们有企业的组织架构，岗位权限对吧？等等这些，那么它实际上面对的是什么？比如说用户有用户的微服务，组织有组织的微服务权限，有权限的微服务等等这些，当然我说的这可能太细致了。这种对功能模块的颗粒度的划分，微服务是倾向于把这个模块画得很小，独立完成一个功能就ok了，不要把它做得很大，它的追求是什么？
我让每一个小的服务都能够独立运行，它是正确的，它是稳定的，它是高效的，那么整体的整个系统整体就会有保障，如果你做一个单体服务特别容易出的一个问题，如果有一个地方出问题了，它可能波及到整个软件，甚至导致你系统的崩溃，这都有可能。
所以这就是微服务，什么叫微服务？用这种多个的小的这种服务来替代整个的一个o in one的这么一种架构，这就是为服务架构，我说的太太白话了，应该给个定义才对。反正微服务最重要的一点，它就是都切成小的服务，通常小服务是单一职责，就是解决一个问题。然后每一个服务可以独立部署，服务与服务之间通过网络进行通讯。然后我刚才说了，其实就是说微服务它是一种软件的架构，它也是一种开发团队的组织结构。
如果你要想做微服务的话，每一个微服务应该有一套人马专门来维护它，这套人马应该是相对独立自治，他们能够高效的协作，如果代码工友咱们的敏捷的思想是代码工友，大家对所有的代码都是了解掌握可以进行维护的，那么其实和微服务的思想是有冲突的。
为服务就是你们仨人作为一个小团队，比如说负责用户管理这一块，你就把这东西给我研究明白，研究精了，他弄得最好，别的事你别管，当然你也可能还有别的任务，反正别人不插手你这事儿。他高度的自制有什么问题，他们仨人门清能够高速高效率的迭代，这就是从组织架构上微服务的一种要求。
你要说微服务最后大伙还都是谁都干乱七八糟的，最后解决不了问题，因为微服务会使整个系统结构变得复杂，异常的复杂，远比咱们这单体结构要复杂的多得多，一会给大家说说微服务通通常都有哪些模块，单体服务通畅这些模块几乎都不用。
好了，这就是什么是微服务，有点唠叨，说说不说不太准了。然后单体服务说我们为什么要上微服务，单体服务有些问题，所以我们才上微服务，说说单体服务的问题。
单体服务通常是它的所有的模块，所有的代码，所有的数据库都部署在一起，由一个团队或者多个团队一起来干这些事儿。
所以它导致的结果第一个就是不足够的灵活，只要有一些迭代，有一些需求变更，我们改了一些代码，整个项目都得变异，重新部署，尤其对于测试来讲，非常灾难性的就是动了一点，我就得至少把主流程全跑一遍，因为我不知道它会波及到哪些，就是你这次修改波及到哪些功能，所以不灵活。
第二个就是不稳定，某些代码出问题的时候它会传播，还有一个就是迭代的效率比较低，但这个是相对的，所以迭代效率比较低，就是说因为它涉及到团队的合作，刚才我说微服务是小小团队对吧？
大团队，所以他的沟通可能就是一个特别大的问题，所以它迭代效率比较低，相比之下微服务的优点就和它的相对应，一个是扩展灵活，那么我们因为都是一一小块的，每一小块的这种伸缩都非常的灵活，你把这一个服务部署在一个就把所有的微服务部署在一个all in one的机器上，ok没问题。
如果你把这些服务某一些它性能要求比较高的，把它单独放在一个服务器上，ok没问题。
甚至于我要提供勇于某些个关键的要有容灾能力的这种微服务，部署在多个节点上来提高性能，提供容灾等等这些也没问题，当然他需要额外的支持，因为服务的相互之间的这种调用其实也是蛮灾难性的，它和单体服务不一样，比如说某一个相对关键的微服务挂掉了，整个系统可能一样也是完蛋，对不对？怎么办？他得有这种所谓熔断的措施，降级的措施，容灾的措施等等，反正它相对灵活，然后得到的结果是相对稳定的。
还有所谓的迭代会效率会高一些，实际上迭代效率高一些，我观点不太乐观，是因为迭代效率高是指一个微服务内部，因为你整体上提高了整个系统的复杂程度，实际上它的运维的成本，它的就是设计的成本，就是前期部署的成本，后期运营维护的成本都会大大的提高，就是这个东西映射到迭代的时候，我要干一个什么事的时候，他做的事其实也非常多，我就是升级一下用户管理的什么这个功能，觉得我就升级这一个小的微服务就ok了，但实际上它涉及的其他的问题依然也有，依然也是赶上效率低的时候， All in one比单体服务还要低。
当然它大部分时候会快一点的前提是什么？我前期要付出巨大的成本，我给大伙说说微服务都有哪些基础的框架，为什么说它的成本很高？微服务的框架大概就是这么一个样子，就是说我有一堆服务微服务在这相互调用，不管是HTTP还是API等等各种方式去调用，它本身网络调用的这种时间成本内存消耗就是这个成本其实是很高的，并且最重要是它复杂度非常高，所以怎么办？
我们得提供这种所谓的API网关，我们有这种网关把这种微服务进行注册发现对吧？这是一般的机制，我们有把这些个服务都在这种网关上，现在有现成的组件，现在现成的组件安装上就可以在这上面进行注册，发现相互调用等等，这是第一步，这能互相调用了。
第二个流控，他有一个比如说成为瓶颈的问题，压力的问题，甚至灾难的问题怎么办？所以你得有流量控制的机制，微服务的系统流控是标配，必须要还有包括流控里边会提供，比如说那种故障会导致整个系统崩溃，那么怎么办？什么熔断的那种机制，降级的机制就都在这实现。
然后还得有整个项目的配置中心，还得有服务监控，就是说我整个服务的健康的情况，还得有什么日志监控，所有这些你肯定这一个少不了，因为它特别复杂，一旦出问题你根本不知道去哪找问题，所以这些基础设施就变得非常的重要。说到这大伙就明白了，我还没写程序了，我就得装上这么独盏统。所以整个系统前期的这种规划设计部署安装，它代价就非常大，很明显它不适合小项目，那么微服务适合什么项目？在什么情况下要用微服务，什么情况下不用微服务？
用微服务现在一种相对一致的说法就是说，当你的项目越来越大的时候，通常我们是通过几步走分步走来实现为服务，也就是说多数的软件系统一上来设计就是微服务架构的几乎没有，这个其实是一个大忌，这是个忌讳，不应该这样做，刚开始都是一个单体服务，之后我们会首先使用一些个微服务的思想，微服务特性，而不是真的微服务的架构，我们把一些模块抽取出来，其实我们把它还用单体服务的那些传统的技术方法那些组件来管理，只不过它就模块就非常清晰了。
这其实就是微服务的特征，我们用这种方法先做改造之后，要上所有的基础框架，再把它完成微服务的改造，并且微服务改造也应该是逐步实施的，不是一个系统，一下子咱休克疗法全上，通常不是这样的，我们通常是一块一块的上，哪一块成熟了，上哪一块，经过一个相对长的过渡的时间，平稳的最后变成了微服务，变成微服务之后，实际上公司规模都会很大了，小公司是干不起为服务的，产品规模也很大了，到那个时候维护运维将成为主要的工作，高速的迭代其实已经不再是主要工作了，也就是说比如说你有原来的功能，你已经实现1000个功能了，之后在近期我是想实现另外的12 15 10个功能，但是我得保证以前的1000个功能平稳高效的运行。
这个时候如果你说我现在已经写完1000个功能了，3个月内我还需要1000个功能，我估计你上不了微服务，你根本没有精力干这些事情，他们相互之间是冲突的。
然后说什么时候上微服务，然后咱们说什么情况下一定不要上微服务，一定不要上微服务，我看了一些资料，大部分人都是这样说的，微服务它不仅是一个系统规模的问题，复杂度的问题，它更重要的是开发团队的问题，其实微服务解决的不是系统的复杂性，而是团队的复杂度，团队管理的复杂度，它一个复杂的系统是不需要上微服务的。
我的一有一个产品非常就这个产品它的架构非常的复杂，其实用微服务是不能解决这些问题的，但是我如果一个产品干得非常大了，那个团队已经非常大了，他们相互之间他们的沟通，他们对产品迭代一相互经常发生冲突，我那代码仓库一天到晚都是在姐姐解决冲突，可能就要考虑为服务了，咱说说什么情况下一定不要作为服务。
第一，初创系统不适合很多人坚信这一点，这是一个非常一致的说法。这个过去一有那么一段时间，那时候上ERP，一般企业上ERP的时候叫上ERP找死不上ERP等死。大系统你只要持续的在发展，其实上微服务是有找死的风险的，当然你不上等死可能也有一定的道理，也有这说法。
反正初创的系统小公司小产品不用上，微服务这个微服务本身会把这系统的复杂度一下子抬起来，你的关注的点就不在产品本身，这一下子让你的开发团队就走偏了，尤其是微服务用很多所谓的新技术，开发团队的那些个人，这些技术人员特别欢迎这些技术，那么他们就会把大量的精力放在这些事上，是反而忽略了对业务的支撑，这是一个特别大的误区，千万要回避这一点。
初创型的公司刚开始做的系统都要回避这一点。
第二个就是团队规模，团队规模就是经典的数据，就是30人以下的技术团队，不适合，你根本就没有精力去管好微服务，刚才咱说了微服务架构本身也是人的组织的形式，它是一种管理模式，你一共就三五个人，你不用拷贝服务，用不着这么费劲，花那么多时间对吧？
这是不对的，但是你说我有100人的开发队伍，这可能你就研究这个事儿了，考虑为服务，考虑中台等等这些可能还是还是有必要的，然后小系统千万不要上位服务，在管理信息系统里边，实际上微服务本身意义就不那么大，但是对于互联网产品确实是为服务的天下。
咱们那些大的成功的互联网的产品都是在用微服务，这确实是真的。
但是如果你的产品日活100万以内，其实我在网上还看见过日活1,000万以内，你都不用想为服务的事，反正100万之内一定不要想为服务，过了100万也许到1,000万的时候日活到1,000万了， ok你考虑为服务这可能是正确的，实际上你与其去花那么多时间人力去搞微服务，不如花点钱买点内存买点CPU ok了，其实那个机器是扛得住的，找找性能瓶颈在哪，花点钱这事就解决了，不一定非得要上微服务，除非你的系统非常大，到日活千万以上多少亿are ok，你肯定也赚钱了对吧？
你的团队也不是三五十个人的事儿，对吧？这个时候考虑为服务，我觉得是有价值的。
技术就是实际的技术的细节我也不是太懂，我就看了一些词，我轻易都不敢念，我都怕念的不对，理解的不对。但是微服务的作用价值思路，我觉得我理解的可能差不多，拿出来跟大家分享，不妥之处大家多提宝贵意见，有什么我说的不对的欢迎大家指正。好，我们这一期就聊到这儿，我们下期再见。
