面对微服务的快速发展，很多人都在学习和了解，希望能对自己的项目有所帮助。了解微服务的真面目后，下一步就是说服自己。如何评估微服务，什么时候使用微服务，什么时候最合适，需要什么样的技术储备和资源投入等等，这些都是你需要去面对和解决的。本文从单体架构、微服务架构、微服务风险评估、微服务落地条件等几个方面探讨微服务的落地过程，希望对大家有所启发。在讲解微服务之前，我们先简单了解下单体架构。1.单体架构单体架构的优点：快速开发和验证想法，证明产品想法是否可行，投入资源和成本，包括人力和物力，相对节省IDE的灵活性会逐渐降低，例如：IDE过载：随着代码量的增加，代码的整体编译效率下降。规模性：不能满足团队规模化、高效化发展的需要。系统开发、测试、部署冲突、效率低等问题只能集中在一套技术栈上。应用的扩展性比较差。海量用户、高并发访问、有限单体应用场景：架构设计的三原则告诉我们，架构需要的是简单、适度、进化。对于项目的初期阶段，单机是最高效、最具成本效益的方式。因为在起步阶段，由于人力、成本、业务熟悉程度、微服务技术积累等因素，如果过度设计，可能会导致建设周期和复杂度急剧上升，导致交付困难、问题百出，从而漏掉时间窗口。最合适也最简单的方式就是单体优先，这是创业公司的特点决定的。当然，设计面向微服务的单体架构也是一种聪明的做法，它遵守系统演化的规律。单体分层的目的：无论采用何种维度的架构分层，分层的核心目的是保证层与层之间的差异足够清晰，边界足够清晰，为架构可能发生的变化提供最简单最小的解决方案。未来修订。比如客户端需要从Android更换到IOS，底层不需要做任何改动，就像更换积木一样。再比如，如果一个设备需要连接到一个新的设备或协议，其他层不需要做任何改变，就可以无缝平滑地连接到任何设备。建议如果前期业务不是很清楚，想要验证idea，证明产品idea是否可行，业务量不大，只限于省级，是建议仅略微改进和升级当前结构。这样的变化比较小，至少可以支撑一定时期的业务增长。2、微服务架构微服务的优势支持更大的业务，可以支持海量用户高并发、海量设备访问，支持分布式多机房、多地域部署，支持服务器无限扩展。支持私有云、公有云、混合云等多种部署方式。所以微服务是大多数互联网公司的首选。微服务的技术门槛高：微服务包括服务描述、注册中心、服务框架、服务监控、服务跟踪、服务治理等几个基本组件。以上每一个组成部分都缺一不可。每个组件的开发都包含很多技术门槛，比如容器技术、持续部署、DevOps等相关概念。复杂度增加：与单体架构相比，所有功能一起打包部署，开发、测试、运维集中进行。微服务会将这些单一的服务进行拆分和部署。业务拆分的粒度是一个难点，拆分后的服务聚合也是一个麻烦。因为服务粒度增大后，相互调用、相互依赖会增加故障排查的难度，需要完善的服务监控、服务跟踪和治理体系。理念的转变：微服务不仅仅是技术的升级，更是开发方式、组织架构、开发理念的转变。初始投资成本相对较高。微服务架构图微服务架构图谷歌或者Bing，你可以看到各种各样的架构图，它们来源于业务和架构师自己的偏好或者粒度。不过各个架构图的基本组件和架构层级差别不大，只是有的细一些，有的粗一些。比如有client层、容器层（K8S）、APIGateway、微服务集群层、EventBus层。至于服务监控、服务跟踪、服务治理，它们是一个完整的系统，粒度并不细。基于这些概念，我对架构图进行了一些细化，这里省略了服务监控、跟踪和治理的部分，然后单独提取出来进行分析。与之前的架构图相比，这里的架构图更贴近业务，粒度更细，虽然省略了一些组件，比如跟踪和治理。上面的架构图主要分为4层，每一层都遵循架构分层的核心思想：关注点分离、职责不同、边界清晰。Layer1:Client：理论上包括所有可以上网的设备，包括移动设备、Android、IoS、Pad、微信、微博、QQ、Web、各自的浏览器、IoT设备等...Layer2：API网关：包括服务注册、发现、认证授权、单点登录、断路器、限流……网关知识点丰富，是微服务的核心之一。如果网关对外提供一个统一的地址：www.jackyfei.com第三层：微服务集群：包括各种具体的微服务，比如垂直划分的业务服务（用户服务，订单服务，...），水平的基础划分或者公共服务（元数据服务，公共服务...）其他微服务的地址可能是这样的：用户服务：1.user.jackyfei.com订单服务：2.order.jackyfei.com元数据服务：3.base.jackyfei.com消息服务：4.msg.jackyfei.com第4层：事件总线：EventBus目的是解耦消息，不允许服务之间直接链接。与SOA的服务总线不同，事件总线相对轻量级，往往基于消息队列引擎进行解耦。目的是弱化服务之间的关联，不直接关联。很多时候会使用相对稳定可靠的企业级RabbitMQ。微服务的架构其实并不难。根据以上架构，各种业务都可以应用。这里的难点在于服务的划分和粒度控制。此外，如何管理膨胀的服务也是一个麻烦事。3.什么时候采用微服务？3.1杨博说这里是架构师杨博（前Ebay架构师，现任拍拍贷研发部总监，高级技术架构师，微服务技术专家）的一些观点：“企业不开始建议直接使用微服务，因为微服务需要前期的基础设施投入，非常复杂，如果你对问题领域不是很了解，你一开始使用微服务的时候，很难划分服务的边界，你的生产力会降低。比较低。而且你在开发上花费了很大的精力，你的产品没有经过市场验证，可能会失败，所以这个选项的风险会比较高。所以，我们推荐单-块优先，单块优先，从低成本和团队成员少开始，不需要太多的研发投入，就可以把一些基础功能交付给客户。成功率更高，客户数量增加，系统的复杂性也会增加。高，单体应用和团队规模之间会产生矛盾，生产力会随着业务复杂度的增加而逐渐下降。所以在一些初创公司，你看到的单体应用比较多，只有一些中大型公司，你会看到微服务架构。满足业务增长的需求，研发效率开始下降，而微服务可以提高研发和交付的效率。这一点需要架构师综合权衡。从个人经验来看，一般团队需要达到100人规模才会考虑微服务。“上面的观点很中肯，对我有很大的启发和帮助。这里的交集如何确定和评价是重点。比如我们推出一个社交网络，就叫它斗心吧。在前期，为了快速上线和验证可行性，可以只开发首页聊天、通讯录、评论等基础功能，产品上线后，经过一段时间的运营，用户逐渐增多，可行性验证通过，下一阶段需要增加更多的新功能来吸引更多的Target用户，比如给这个社交斗信增加朋友圈、消息通知、游戏、电商等功能”一般这时候需要大规模扩容开发者，支持多功能的开发。如果此时继续使用单一的应用架构，如果将多个功能模块混合在一起进行开发、测试和部署，不同的功能会相互影响。打包部署需要所有功能都测试OK后才能上线。不仅如此，多个功能模块的混用对于在线服务的稳定性也是一个巨大的挑战。比如A开发的一个功能，由于代码编写考虑不周，上线后出现内存泄漏，进程运行一段时间后异常退出，导致部署在该服务池中的所有功能都无法访问。根据我的实际项目经验，一旦超过10个人同时开发单个应用，就会遇到以上问题。这个时候就该考虑服务拆分了。》——胡忠祥（微博微服务技术专家）到目前为止，我们在采用微服务的时候已经很清楚了，关键是业务复杂度和团队规模，而业务复杂度和市场窗口是权衡和决定的首要因素.3.2微服务落地条件评估一般情况下，业务系统引入新技术必然会增加架构的复杂度，在做具体决策之前，首先要认清新架构会带来哪些新问题，你和你的能否团队解决这些问题？如何解决？是自己投入人力建设，还是使用业界的开源解决方案？如果你和我一样是微服务的旁观者或学习者，那么下面的测评或许对你有帮助，供参考3.2.1落地方式选择不同的落地方式来决定不同的资源分配方式一：借力外部架构咨询g公司提供架构DEMO和培训服务，助推内部团队技术转型升级。方式二：招聘经验丰富的人员进来，自己研究搭建架构，做内部培训，促进团队的技术升级。建议：如果急用第一种方法，因为很难招到匹配的人才，等不起。但无论哪种方式，对于团队来说，都需要一定的技术人才储备，以方便后续的交接和运维。3.2.2人才储备分为研究型和应用型两类人才。研究型以技术攻关为主，负责微服务核心组件的研发，如服务发布与订阅、服务跟踪与监控、服务治理等；应用类主要负责技术理解和应用。3.2.3技术储备微服务相关技术栈和微服务外围技术栈。周边的技术栈包括领域驱动设计、持续交付、分布式至少、负载均衡、CAP理论、缓存原理、DevOps和容器化技术。3.2.4团队规模评估杨波在规划微服务开发团队时粗略估计了100人左右，但并未详细说明需要多少开发人员。可能笔者工作过的公司都是大厂，在人工成本控制上并没有那么大的负担。对于中小企业来说，人力是最昂贵的成本。一定要用微服务怎么办？对于微服务的团队规模，众说纷纭。有人说它需要数百人；有人说它需要数百人。有人说它需要大约10名精锐士兵；;有人说懂微服务的架构师也能搞定。这些说法比较笼统。如果要使用微服务，人力评估包括人力、能力、人数等，这些因素还是很重要的。毕竟，成本是商业的本质，不客观的规划可能会导致项目的失败。.哪些方面决定了微服务的团队规模？我觉得至少应该从以下两个维度来评估：业务规模：如果你的业务结构很复杂，有仓储系统开发、ERP系统、OA系统、订单系统等等等等，业务越多，需要的人越多（这里的人数是指后台开发人员的数量）。技术能力：另外别忘了，非功能性的开发，比如API网关、服务跟踪、治理等，也是需要人来开发和维护的。这些非功能性的核心组件需要多少人，由于缺乏完整的开发经验，再加上个别组件，比如跟踪系统，开发的程度可深可浅，开发周期可长可短.与合理的建议。可能1个人才两周就够了，也可能2个高级开发人员分工三个核心组件，两周就够了。或者架构外包，只要交接人员跟得上，也是一种解决方案。总结：精通微服务落地体验的架构师必不可少。围绕架构师的一组高级开发人员是根据实际业务确定的。一般一个开发者负责2-3个核心模块。它不应该太多。比如目前有8个核心模块，对应的人数大概是3-4人。3.3转微服务风险评估3.3.1改写覆盖面广由于架构层面的调整，之前保留的代码大多是解耦较好的代码，如前端代码、采集服务代码、部分业务逻辑代码.现有框架的冲击面比较大。3.3.2复杂度高由于微服务是一个概念和思想，是一种新技术，它有多种架构实现方式和技术方案。因此，对于技术人员来说，比选本身就是一种考验。另外涉及的技术面比较广，所以复杂度和门槛都比较高。然而，这项技术起源于亚马逊。经过近几年的发展，虽然还在发展中，但是已经比较成熟了。3.3.3人员配置微服务架构的工作量主要集中在后端，对后端开发人员的技术水平要求高，主要是熟悉微服务原理和开源组件，需要有整体的微服务意识。本人暂时没有整体的微服务开发意识和经验，需要培训后进行转型升级。3.3.4合作方式如果利用外部架构力量助推架构升级，与架构单位的合作不是简单的外包，涉及的范围会更广，周期会更长，才能完成交接。包括对我们业务架构的深刻理解，然后在业务架构的基础上绘制扎实的技术架构蓝图。然后根据技术蓝图进行实施（不建议只提供架构方案，由其他单位负责实施），包括新系统的开发和旧系统的升级。当然，这次升级是顺利和过度的，不会影响业务窗口。.3.4合理的拆分姿势如何正确拆分？这里的正确指的是合理，因为没有绝对的标准。根据以往的经验，分为纵向和横向两种划分方式：3.4.1纵向拆分是从业务维度进行拆分。该标准根据业务关联程度确定。关系密切的业务适合拆分成微服务，功能相对独立的业务适合拆分成微服务。比如上图中的订单服务和用户服务。另外，粒度太小，服务聚合是个坑，粒度太大，分和不分就没有区别了。3.4.2横向拆分是从共同的、独立的功能维度进行拆分。该标准基于是否有多个其他服务的公共调用，依赖的资源是独立的，不与其他服务耦合。比如上图中的元数据服务和消息服务。3.4.3小结借用《微服务设计》的一句话：“你对一个领域了解越少，就越难为一个服务找到合适的限界上下文……错误的服务边界划分可能导致领域的频繁变化contextbetweenservices.context.collaboration,andthiskindofchangecostsmore...”4.SOA和微服务因为SOA和微服务有着千丝万缕的联系，这里简单放一张双方的对比图，算是一个小知识点：两者architectures背后的意图不同：SOA试图集成应用程序，一般使用中央管理模型来确保应用程序可以互操作。微服务尝试部署新功能，快速有效地扩展开发团队。它侧重于去中心化管理、代码重用和自动执行。五、小结最后，让我们重温一下前人的经典名言：分配的第一定律是“尽量不用分配”。软件行业的从业者，尤其是不再写代码的从业者，总是期待银弹，但银弹是不存在的。微服务依赖于“基础设施自动化”。微服务不是“灵丹妙药”。或者回到我们架构设计的原则上，遵循简单、适用、进化的原则，那么你的选择可能会变得不那么纠结。文章引用从单体架构迁移到微服务架构《微服务设计》作者：[英文]SamNewman出版商：人民邮电出版社采用微服务需要应对的4个挑战为什么要使用微服务？
