《微服务进展缓慢的5个难点》描述了实施微服务常见的主要障碍。本文提出了7个步骤来解决上述5个困难。每一步都包括管理和技术建议。如果以上5点让你膝盖中了一箭。所以根据我个人的经验，全面解决微服务实施难点的第一步是：第一步：以终为始，先建立一个独立的敏捷微服务团队。我们对微服务的期望是：可以独立开发，独立部署，独立发布，去中心化管理。所以，让我们先建立这样一个团队。为了实现上述目标，本团队将采用各种方法（例如：DevOps，全功能团队）来解决阻碍“自主开发、自主部署、自主发布和去中心化”的问题。根据康威定理，系统架构会慢下来，慢慢走向“去中心化”。要知道，这个过程会打破现有的大系统自上而下的过程，以更高效的方式构建新的组织结构。你唯一需要做的就是充分信任团队，把它看做是微服务的技术管理创新，不要用老办法管控团队的运作，会损害团队的士气管理建议：让微服务团队完全脱离之前的工作，专注于微服务在工作中，如果分心，同时做几件事情，一切都不会完美。给微服务团队一些权限，以满足需要“全功能微服务团队”的s。在执行过程中，存在依赖关系，阻碍了进度。您需要标记依赖项。代码中的依赖很容易看到，但组织中的流程依赖却很难发现。为了避免团队在外部产生“依赖惯性”，让团队自己去寻找解决内部依赖的方法。组织流程的变化也是微服务架构的重要产物，而不仅仅是微服务代码或基础设施。技术建议：为微服务构建新的代码库，而不是从原来的代码库上Clone或复制，避免与原团队的开发依赖。构建一个独立的持续交付流水线，最好是通过“流水线即代码技术”（如Jenkinsfile）自动生成流水线。第二步：构建微服务《电梯语音》建立了微服务团队之后，接下来就是选择第一个微服务来实现。但是“这个微服务应该有多大，边界在哪里”是个问题。这不需要严格的设计和反复的迭代论证，只要找到当前的痛点或者想完成一个假设，就可以上路了。使整个过程更轻，而不是更重。我的建议是通过“微服务电梯演讲”的方式来定义微服务。格式可以是：（XX微服务）用于解决（解决一个存在的问题）在（一个痛点场景）的情况下，从而（达到什么效果）提高（微服务的价值）例如：（订单查询微服务）用于解决（访问量快速增加导致应用整体性能下降）在（订单查询次数快）的情况下，从而（将订单查询请求分离）到improve（其他功能的表现）当微服务的电梯演讲时，团队可以以此为原则着手。当遇到与现有系统冲突的问题时，替换几个词可以帮助您做出决定。（语言在某种程度上也是有魔力的）用“删除”代替“拆分”。例如：“将现有系统中的订单查询功能拆分”为“去除现有系统中的订单查询功能”。思路已经从一个团队负责两个系统转变为两个团队负责两个系统。将“集成”替换为“调用”。例如：“用户注册和用户登录需要整合”修改为“用户登录服务需要调用用户注册服务的信息”。思维方式的转变使得两个系统之间的关系更加精确，从而理清了微服务之间的关系和通信方式。给管理层的建议：打印出微服务电梯谈话并挂在墙上，让团队成员牢记在心。这将加强组织对微服务边界的理解。电梯间距可能会随着团队的反思和学习而改变，但重要的是团队要形成共识和共识。不要指望第一次就能正确划分。分区是一个持续的权衡过程。技术建议：明确微服务的职责和边界后，再看代码，不然会受代码复杂度的影响。领域驱动设计(DDD)可以帮助您更好地划分微服务。领域驱动设计遵循“关注点分离”（Separationofconcerns，SOC）的原则，提出更加成熟和清晰的分层架构。如果您不知道领域驱动设计(DDD)，那也没关系。简单地使用“关注点分离原则”也可以帮助您实现这一目标。比如：把大流量的接口和独立部署的接口分开，把读写数据库的API分开，静态访问和动态访问分开……第三步：以最低的成本发布第一个微服务注意两个关键点：一是“最低成本”，二是“释放”。上面说了，微服务架构本身就决定了微服务一定是低成本、低风险的渐进演进。最大的浪费在于：职责/层级划分明确的组织沟通结构。“时间长，反馈慢”的动作习惯。先进的技术栈，学习成本高。因此，“最低成本”包括以下三个方面：最精简的独立敏捷全功能团队。最快的时间。成本最低的技术堆栈。另外，很多微服务“爱好者”因为害怕失败，总是把微服务技术放在“实验室”里。勇于面对失败，面对生产环境中的真实问题，但要采取一些规避风险的措施。管理建议：尽量让现有的微服务团队学会自己解决问题，成为全功能团队。如无需要，不会增加新人手。“与其撕开喉咙，不如松开你的手臂。”先行动起来，在前进的过程中解决问题。先考虑***是怎么发布的，按照发布流程倒推。技术建议：根据当前的技术采用情况，选择成本较低的技术栈。使用动态特性开关（FeatureToggle），可以在发布后动态控制生产环境微服务的激活，降低失败风险。如果采用特性开关，则必须建立删除特性开关和对应旧代码的时间，一般不超过两个月。否则后期大量的特性切换会带来管理成本的增加和代码的混乱。由于团队比较小，功能也比较单一，不建议使用分支来构建微服务，而是应该使用单主干的方式进行开发。第四步：实现速赢（Quickwins）、展示（Showcase）驱动的开发，在刚开始改造微服务的时候肯定是一个试错的过程。设定过高的目标会造成压力并使团队士气低落。而设定每日的短期目标，速战速决，将持续激励团队的士气。这是一种非常有效的“设置一天结束的产出来确定今天需要做什么”的方法。DailyShowcase是一种提高输出的方法。每天与团队分享今天的工作，使团队能够共同学习。并以当天或明天的展示为目标。每个单独showcase的内容一般不超过20分钟，一天的showcase时间不超过1小时。它可以是早上或下班后的展示。常见的速赢目标如下：构建第一条微服务流水线。第一个微服务HelloWorld上线，构建第一个微服务自动化测试。以下目标不适合作为速赢目标：构建微服务DevOps平台。完成整个产品的微服务架构拆分。构建微服务自动化运维体系。给管理层的建议：为防止团队画大饼，完成每日和每周的工作目标即可。微服务开发本身并没有很长的周期。迫使团队产生一些东西，以便关键输出可以推动开发。输出不一定是代码或基础设施。一个总结，或者学习文章的分享，甚至踩过的坑，遇到的问题都可以展示出来。目的是建立一个自主学习的团队。最重要的是坚持，不要计划太远。一个多月后，需要反思是不是目标范围太大了。以天为单位拆分任务，超过一天的任务必须拆分。无法在一天内完成的工作需要拆分成阶段性输出。如果每天都能配对交换对，showcase就没有必要了。使用敏捷看板可视化所有任务和管理任务是了解现状的最佳方式。技术建议：想办法尽快把第一个微服务发布到生产环境，生产是最重要的。完成HelloWord的发布后，需要考虑如何改进发布流程。而不是急于准备下一次业务启动。第五步：代码没有动，DevOps先微服务解耦的本质是通过一些工具将代码内部的复杂性转化为外部的复杂性。将代码的内部复杂性划分为单独的微服务，以降低整体复杂性和架构风险。DevOps技术和工具将在这个过程中大量使用。也可以说，微服务是DevOps文化和技术发展的必然结果。以J2EE的应用为例，传统的WebServer+AppServer+MiddleWare+Database的架构已经被更多的基础设施工具所取代，需要更少的编程工作量。因为基础设施比应用代码更稳定，更有利于扩展。我把微服务的技术架构比作“台上演”：首先我们要搭建一个微服务交付和运行的平台，然后让微服务上台表演。这个平台不需要一开始就很完美，只需要满足生产上线的必要要求即可。在许多企业中，这部分由Ops团队在交付流程结束时进行检查。因此，将最后一级的确认工作放在最前面，可以减少后期的返工和不必要的浪费。以前，软件开发和测试过程是分开的。但是随着DevOps运动的兴起和各种自动化运维工具的兴起，这种必要性已经降低了。只要有足够的自动化测试来保证质量，就可以快速部署微服务并将其发布到生产环境中。环境。一开始，即使发布一个HelloWorld程序，也说明微服务持续交付运行的平台已经搭建完成，微服务的交付流程已经打通，这是重中之重。在技??术交付产品方面，DevOps主要交付两点：持续交付流水线。微服务运营平台。为了保证微服务的高效交付，需要以自动化的方式将两者有机地结合起来，而不是相互依赖。让开发和运维的矛盾变成“自动化开发和运维的矛盾”。另外，DevOps不仅仅是指一系列的技术，更是一种工作方式。从团队合作的角度来看，DevOps必须做到：让Dev和Ops共同参与决策、设计、实施和维护。团队是完全自主的，打破了对现有流程的依赖。不断追求改进，让团队形成改进的团队文化。给管理层的建议：“让新项目快速投入生产”给了团队继续前进的动力***。如果你的组织是Dev和Ops的独立组织，请先咨询Ops工程师。最好的是能够在微服务团队配备一名运维工程师。如果不具备实施DevOps的条件，微服务架构就必须从运维端入手，而不是从开发端入手。技术建议：微服务平台一开始可以非常简单，然后逐渐增强和扩展。但它必须部署在生产环境中。如果想使用现成的微服务平台，可以参考SpringCloud。通过灰度发布技术，微服务运行平台可以在生产环境中并行运行。通过使用灰度发布技术，逐步提高微服务在生产环境中的使用比例。Infrastructureascode是DevOps的核心实践，可以帮助开发者在本地机器上快速搭建类似于生产环境的开发环境，减少环境的不一致性。可以使用Docker、Ansible、Vagrant等工具来完成。基础设施应该对微服务透明。微服务不应该也不需要知道运行环境的细节。只要它能正常启动和执行业务，它的任务就完成了。因此，基础设施代码应该和微服务业务代码分开，微服务不应该告诉平台如何部署。服务注册和发现是微服务架构的核心部分。Consul和Eureka在这方面做得最好。部署和发布应该分开。第六步：除了提交代码和发布，微服务平台上的一切都应该是自动化的。完成微服务基础架构和交付流程后，就可以开始实施微服务业务了。这时候就需要根据电梯语音划分的微服务来开发业务逻辑。在以DevOps的方式工作一段时间后，团队应该养成一些自动化的习惯，如果没有，他们应该检查他们的自动化水平。完美自动化的理想状态是，除了代码的提交和发布之外，每一个过程和中间的环节都应该通过自动化的方式来完成。当然，也有不能自动化的部分。根据我的经验，之所以不能自动化，主要是来自流程管理的制度要求，而不是技术上的困难。这通常是由于组织没有根据微服务进行流程更改造成的。这时候就需要检讨不能自动化的部分是否有必要。另一方面，虽然自动化可以大大缩短微服务的交付时间，提高微服务交付的效率。但是，自动化需要同时考虑安全因素和风险，不能两全其美。对于生产，可用性和安全性是最重要的部分。重点自动化：自动化功能测试（UI/集成/单元/回归）自动化构建自动化部署自动化性能测试自动化安全扫描管理建议：团队成员自发地进行自动化改进，这对未来批量开发微服务带来很大好处。一开始不要追求全自动化，自动化需要一定的时间。根据团队的进度适度进行。技术建议：使用TDD进行开发，不仅可以提高质量，还可以完成测试的自动化。契约测试可以解耦微服务提供者和消费者的开发。但要注意始终保持合同的有效性，必须先改合同再制定。注意自动化的安全风险。机密信息需要独立管理，例如使用HashicorpVault之类的服务。关键步骤需要通过自动和手动两种方式准备，必要时可以干预自动过程。利用git的hook技术，可以在代码推送前完成测试和静态检查，提高CI的成功率。第七步：总结复制成功经验，建立微服务交付节奏。当第一个微服务完成后，不要急于开始下一个微服务的开发。相反，有必要对可重现的经验进行总结，找出微服务开发中的经验教训，并将其总结为可重现的经验和产出。以下是一些需要总结的关键输出：规范从微服务开发到发布的端到端流程。微服务开发技术质量规范。在团队合作中坚持的最佳实践。常见技术问题总结。通过以上关键输出，可以扩充微服务开发团队。这个时候有微服务开发的老司机，和刚加入开发的同事一起，风险会比较低。给管理层的建议：初期可以每周召开一次回顾会议，团队需要快速反馈和调整。不要急于扩大团队，在成功经验稳定并形成模式后迅速扩大。避免冲淡微服务良好的开发氛围，一开始慢慢扩充团队。新老成员??比例不得超过1：1。虽然微服务平台趋于稳定，但在微服务规模化之前，不要让团队缺少Ops成员。注重知识的传递和人才的培养。技术建议：在微服务应用规模不大的时候，不要急于形成微服务模板，这样会限制未来微服务的发展和扩展。在微服务未实现可扩展性的情况下，不要放松对微服务平台和交付流程的改进。实现微服务最快的交付和发布。
