作者丨崔浩策划丨孙淑娟【.com原稿】业务的快速发展和不断变化的动态组合，一直在推动云计算以IaaS、PaaS和SaaS的形式不断发展，并实施微服务程序也需要与时俱进。放眼行业，谷歌、沃尔玛、亚马逊等科技巨头已经开始不同程度地使用微服务架构和解决方案。他们期望微服务提供的模块化解决方案作为业务流程再造的基石，以适应更灵活、更复杂的业务场景。从单体架构到微服务架构单体软件架构使用单一的方法和模型来构建应用系统。应用虽分部，但业务逻辑易于理解，开发周期可控。特性，但单体架构的可扩展性一直是被大家诟病的短板。单体架构由于其自身的特点，在扩展性上存在各种限制，如资源可用性差、部署周期较长、无法持续交付、技术栈单一无法发挥技术多样性等。同时，架构中单个应用程序的一个故障会影响整个软件。企业期待通过模块化和动态组合来解决上述问题，因为模块的动态组合对于灵活复杂的业务逻辑更具有业务驱动性。这正是BatteryVentures的AdrianCockcroft所说的：“微服务是一种松耦合的、面向服务的架构，上下文有限。”松散耦合的模块会根据应用的需要进行合理组合。每个服务都可以通过不同的技术栈实现，可以独立扩展以应对业务调整。这意味着服务需要协同工作，一个应用程序的输出将成为另一个应用程序的输入，服务也可以通过API进行有效通信。同时，由于微服务的隔离机制，可以有效监控各个服务的安全性。比如使用Python开发的服务不需要其他技术能力的支持，这在微服务开发中很常见。虽然服务内部的技术不同，但在协同工作时，可以统一规定服务以及对外的接口和传输方式。例如，使用（REST）API在服务之间进行通信，使用HTTP协议传输数据，使用统一资源标识符（URI）与前端系统（Android/iOS，HTML5/JavaScript）进行通信。举个例子来说明单体服务和微服务的区别。单体架构就像希腊石像，而微服务就像乐高积木。如果石雕有一部分损坏，则必须将整尊雕像报废重建。乐高积木只需要更换部分组件。显然，微服务在构建复杂系统时具有优势，但在实现过程中需要平衡速度和安全性。众所周知，在DevOps和持续开发与持续集成（CD/CI）领域，微服务可以提高应用开发和交付速度，尤其是针对复杂的业务场景，提高交付速度。但是，由于微服务独立、去中心化的特点，我们也需要关注各个服务的安全问题。因此，在微服务架构的设计和实现中，我们需要考虑通过统一的服务编写或实现标准来规避安全风险。建议创建一个“centralkeydeliverable”（centralkeydeliveryprinciple/standard），所有服务都围绕这个标准设计，避免个别服务。微服务实施模型第1阶段：专注于敏捷性和响应性在线流媒体服务Netflix以其点播服务而闻名，为用户提供优质的USP体验。微服务的架构大大缩短了交付周期，提高了开发频率，同时也提供了持续的服务交付。从应用特性来看，每个应用所需要的资源量是不相等的。某些应用程序可能比其他应用程序更频繁地使用，因此需要更多资源来支持它们。以核心业务能力为架构中心，其他服务为核心能力的扩展。比如视频播放是核心业务。会员点播、订阅、积分等都需要围绕这个核心业务发展。这些围绕核心业务的服务可以以微服务的形式存在，但需要与核心业务建立良好的调用接口和通信方式。.因此，可以说核心服务和企业服务可以从以下两个层面来定义：功能扩展：围绕核心服务的其他服务作为应用功能的扩展。对于Netflix来说，核心服务无疑是视频播放，而其他周边服务则会根据用户需求的增加或变化进行调整。这种根据业务和用户需求进行扩展的服务，需要能够在不影响核心服务的情况下自由扩展。这里，就需要利用微服务的敏捷特性。定义好扩展服务和核心服务之间的接口和协议后，就可以根据用户需要对服务进行扩展。资源能力的拓展：如果说功能层面的拓展与业务挂钩，那么资源能力的拓展则与流量挂钩。由于Netflix本质上是一个资源/服务的提供者，而消费资源/服务的用户数量是不确定的，如何实现资源伸缩是Netflix需要考虑的问题。在真实的业务场景中，用户访问量或网站流量是有波动的，因此Netflix网站提供的资源也应该随着用户访问量的变化而及时调整。在微服务架构中，可以灵活调整资源的分配。Netflix以resources作为5个用户扩展或收缩资源的步长。事实上，许多计算机技术都使用类似的想法来解决资源短缺问题。肯定。例如MySQL中的VARCHAR类型，也是以变长的方式扩展了字符的存储空间。Phase2：管理安全和源代码成熟度的统一虽然在微服务架构中每个服务可以使用不同的技术栈来完成不同的业务功能，但毕竟所有的服务都是为了一个业务目的，都存在于一个系统中。因此，在微服务的实现过程中，需要注意对每个单独服务的安全管理。以货币交易系统为例，如果采用微服务架构，那么转账服务、工资支付服务、零售交易服务都需要遵循相同的规则。安全级别。这一点在微服务实现过程中尤为重要，也是对微服务架构安全管理能力的考验。也就是说，为微服务定义了安全准则，包括数据安全、通信安全和访问安全。它甚至提供了通用的微服务来封装这些安全规则，其他服务只需要调用相应的标准服务或组件，这样即使是使用不同技术栈的服务也可以遵循相同的安全标准。除了安全标准，微服务还需要管理代码成熟度。每个服务源代码的成熟度级别都需要标准化，以便在服务提供阶段提供特定的目标和解决方案。但是，如果为每一个服务源代码定义成熟度级别，显然不可能达到统一的架构级别。此外，多个团队将参与微服务的开发过程，代码可能由多个后续团队维护。因此，代码成熟度的等级需要从整个系统的高度来定义。否则，不仅服务无法应对复杂的业务变化，也无法实现与整体架构一致的目标（速度/安全）和系统扩展性。因此，个别服务的源码变更需要与系统整体源码的成熟度保持一致，从而降低两者长期不同步的风险。简单来说，单个微服务的代码成熟度和整体架构需要保持一致。众所周知，一个软件的非功能性需求包括：高性能、可用??性、可扩展性、可伸缩性和安全性。每个维度都可以定义指标和成熟度级别。例如，软件安全的成熟度模型将从监管、构建、确认和部署四个方面进行定义。每个类别会分为三个等级来定义成熟度的等级，这里不再赘述。Phase3：保证方案和系统运行的可扩展性系统实施后的返工成本非常高，因此在系统设计初期就需要考虑业务扩展和存储访问的增加，一般情况下，有必要提前计划。尤其是在业务场景复杂、业务环境多变的情况下，应用架构的扩展和伸缩需要与业务发展和收入相匹配，避免两者不一致。例如业务量增加，系统无法承载大流量，或者业务扩展后在原有核心功能上增加了其他功能，系统架构对功能扩展反应迟缓，或者无法扩展.需要注意的是，系统方案需要顺应业务扩展，兼容第三方软件，随着业务的增长，重新部署周期保持在平均水平，保持系统流量波动和运营成本一致。另外需要注意的是，系统功能层面需要有长远的考虑，降低系统的复杂程度，避免后续功能的引入对系统的影响。例如在系统设计初期，可以根据实际业务进行界面设计，根据当时的情况进行业务实现，以应对业务的变化.例如，要创建一个中间平台作为卡车服务和客户之间的中介，那么就需要考虑接入不同的卡车服务，包括：个人卡车用户、集体卡车用户和平台。同时，还要考虑结算服务，针对不同的结算方式（微信、支付宝、网银），或者针对同一支付方式的不同支付主体（例如：网银包括：工商银行、建设银行、招商银行等）接口，所有业务都针对该接口进行编程。一旦实现的对象，比如支付主体从微信切换到支付宝，或者网银主体从工商银行切换到招商银行，只需要更换一个新的服务实现即可。服务之间的接口不需要调整。接口的定义在架构设计阶段是可以精确预测的。阶段四：保证单个服务的独立性和完整性——服务作为解决方案整个微服务架构由多个独立的服务组成，每个服务都是一个独立的解决方案，单个服务尽量不依赖其他服务。它是一种依赖，是对接口的依赖。这种设计就像乐高积木，每个服务各司其职，很容易被替换和扩展。对每一个服务，定义标准的功能描述、输入输出参数、消息传输格式，并在系统内部公开这些信息，让其他服务知道该服务的功能和服务边界是什么。这种方式实现了服务之间的无缝对接，避免了重新发明轮子的尴尬。同时，也为数据中心和服务中心奠定了基础。以沃尔玛实验室为例，系统架构每月要进行多达30,000次更新，而这些更新是由3,000名工程师使用OneOps平台完成的。由于服务的云化，提高了开发效率，降低了新业务的开发难度，增强了组织在不同领域的竞争力。也就是说，当企业面临复杂的环境时，可以利用哪些不变的服务组件（粒度足够小）以及企业对市场和业务的理解，通过组合、集成和扩展，快速高效地构建新的应用。快速适应新的商业模式，服务客户，占领市场。阶段五：用好流程、工具和组织架构企业需要明白，要想成功实施微服务，需要对系统构建流程进行改革，这有别于传统单体应用的分层开发模式。开发者的工作层次不同，前端，后端，H5，甚至后端可以分为面向数据库和面向业务开发。这种方式在微服务环境下已经不适用了。开发人员必须知道他们是微服务的主人。你开发的微服务代表你的产品，它会被系统中的其他服务消费，也就是其他服务。那是你的客户。因此，您必须是该服务的唯一负责人。只要与这个服务相关的一切都需要关注，这就迫使开发人员成为全栈工程师，这对人、组织和开发流程都有更高的要求。微服务的开发者需要将服务作为产品来管理，包括设计、编码、UI开发，同时还要保证运维过程中的质量交付和故障排查升级。看起来开发人员的责任增加了，但是有一些DevOps工具通过持续集成和交付来辅助微服务的开发，以确保单点故障(SPOF)不会影响其他服务。同时也引入了容器化的部署方式，Docker部署方式就是一个明显的例子。Docker的部署只针对单一服务范围，提高了容器镜像（CI持续集成）使用的标准化和效率。相对于传统方式的整体发布，容器化部署工具在发布成本和试错成本上是最划算的选择。第六阶段：整体系统实施策略微服务架构是近几年随着业务的发展而兴起的。从整体系统的角度来看，如何实现微服务架构一直是架构师面临的问题。一个新系统可以完全重启，但是为遗留系统实现微服务架构并不是一件容易的事。这里提供三种策略供大家参考，如图：第一种CreamScoopStrategyIceCreamScoopStrategy：是MartinFlower提出的一种策略，也称为绞杀法。可想而知，有一大桶冰淇淋。这桶冰淇淋代表了现有的建筑。你可以用勺子从桶里挖出你想要的冰淇淋。挖出来的部分就是要拆分的服务。最终，这桶冰淇淋可以被挖掘成独立的服务，服务中包含不同的业务逻辑。这种方式是逐步修改原有系统，逐步拆分服务试错，再过渡到单独的资源上运行。每次分裂对系统的影响很小，但整个系统的分裂和重建需要很长时间。第二种乐高方法策略（搭积木）把原来的系统想象成一个大的乐高积木，我们只需要给它添加小的乐高积木模块，添加的小模块就是一个一个的微服务。这样就不需要对老产品进行调整，新功能通过微服务的方式实现并集成到老产品中。但是，需要有一种方法将微服务与旧产品连接起来，这里会用到接口编程和适配器模式。三是核战略。就像策略的名字一样，我们需要重做旧系统，重建微服务架构。说来容易，分析重建需要花费大量的时间。这个周期比较长，成本也高。更高。微服务架构实施战略阶段七：调整态度，面对转型在实施微服务架构的过程中，领导风格和公司文化起着举足轻重的作用，而这两点无论在什么情况下和可变因素下都是复杂和模糊的.即没有好的建议和想法，只能适应业务变化，调整组织能力和领导方向。但有一点是肯定的，企业需要不断观察和分析市场变化，倾听客户的声音，使变化的频率与市场波动同步，营造一种自我学习、不断适应的企业文化。领导法需要在企业文化的基础上不断评估外部需求，从而拓宽视野，简化最终结果并不断迭代，因为没有人能保证开发出完美的系统和产品。只有适应市场变化，不断提升自身能力，不断打磨体系，才能立于不败之地。以终为始，打造领导力，调整组织架构，打造企业文化，让利益相关方信任和参与，形成企业的核心竞争力。总结本文从业务开发入手。为了适应复杂多变的业务场景，系统从单体架构向微服务架构演进。独立的服务、功能的可扩展性、资源的可扩展性，使得微服务架构在复杂的业务环境中占有一席之地。但正是因为这些特性增加了微服务实现的复杂度，本文采用七阶段模型来帮助企业实现微服务架构。包括：专注于敏捷性和响应能力：在功能和资源级别进行扩展；安全和源代码成熟度：创建安全和成熟度标准；解决方案和系统操作的可扩展性；服务的独立性和完整性；使用流程、工具和组织结构；实施整个系统的策略；调整姿势以面对变换。作者介绍崔浩，社区编辑，资深架构师，18年软件开发和架构经验，10年分布式架构经验。他曾经是惠普的技术专家。乐于分享，撰写了多篇阅读量超过60万的热门技术文章。《分布式架构原理与实践》作者。【原创稿件，合作网站转载请注明原作者和出处为.com】
