微服务是如何发展的，以及它们为何如此重要

维基。 在微服务上。

定义为：一种软件开发技术 - 面向服务的架构 （SOA） 架构风格的一种变体，提倡单个应用程序的集成。

划分为一组小服务，服务之间相互协调和合作，为用户提供终极价值。

也许微服务最重要的单一特征是，由于服务很小，可以独立部署，因此不再需要繁琐的操作来更改应用程序中的一行文本。

在微服务模型中，组件是独立部署的，并通过 REST、事件流和消息传递的某种组合进行通信，因此可以针对该服务优化每个服务的堆栈。

技术一直在变化，随着更理想的技术的发展，由多个小型服务组成的应用程序变得越来越容易，成本也越来越低。

使用微服务，可以单独部署单个服务，但也可以单独缩放它们。 好处是显而易见的：如果操作得当，微服务需要的基础设施比单体应用程序少，因为微服务只支持需要它们的组件的精确缩放，而单体应用程序不需要整个应用程序。

例如，HC Service Mesh是一个基于Istio和容器技术的微服务治理平台，以非侵入的方式为多种语言和不同部署形式的异构应用提供服务治理、服务监控、安全控制等微服务管理能力。

可以将业务通信、观察、安全能力下沉到基础设施层，降低分布式应用开发的复杂度，减轻应用运维负担，推动企业应用整体向服务治理平台迁移，完善IT系统。

整个旅具有承载能力和高可用性能力。

1）独立部署服务，每个服务都是一个独立的项目，可以独立部署，不依赖其他服务，耦合。

低。 2）服务启动速度快，拆分后服务启动的速度比拆分前快得多，因为依赖库少了，**也少了。

3）更适合敏捷开发。

敏捷开发基于用户需求的演变，并采用迭代、循序渐进的方法。 服务拆分可以让你快速发布一个新版本，你只需要发布对应的服务来修改哪个服务，就不需要重新发布整个服务。

4）专职负责，专人团队负责专项服务。当业务发展迅速时，研发人员会越来越多，每个团队可以负责相应的业务线，服务分离有利于团队之间的分工。

5）服务可以按需动态扩展，当一个服务有大量的访问量时，我们只需要扩展服务即可。

6）复用，每个服务都提供一个REST API，所有的基础服务都必须抽取，很多底层实现都可以以接口的形式提供。如果您想了解更多信息，我建议您查看 Speed Cloud，他们是一个全栈云数字尊重原生。

一家技术服务提供商，提供云原生应用和数据平台产品，包括容器云PaaS、DevOps和微服务。

微服务是国内领先的基于微信公众平台的营销工具，致力于提供全方位的微信运营服务、微信代理运营、线下活动推广服务，真正实现为客户提供一站式服务。 [1]

平台为商户定制了“个性化管理、营销推广、客户关系管理、会员卡管理”等多个重要运营管理模块，涵盖微信管家、微信应用解决方案、微信客服客户端、人工微信客服四大部分。

服务方式的飞跃。

用户体验升级。

微时代的资源共享。

个性化服务升级。

脑筋急转弯、谜语、歌名、多样化的微互动营销活动，不仅可以增加用户体验，还可以带动用户下单。

服务成本可控。

按体积收费，无论座席可用性如何。 成本，每一分钱都花在最前沿。

微服务的特点如下：

1. 单一责任原则：每个服务应负责一个单独的功能，这是 SOLID 原则之一。

2、独立部署、升级、扩容、替换：各项业务可单独部署和重新部署，不影响整个系统。 这使得升级服务变得容易。

3. 支持异构多语言：每个服务的实现细节独立于其他服务，实现服务之间的解耦。

团队可以为每项服务选择最合适的开发语言、工具和方法。

4、轻量级：微服务通常由轻量级分布式服务框架承载，采用P2P通信，无中心节点，性能可以线性增长; 减少第三方软件依赖，减少类冲突和冗余依赖，集成升级更方便。

微服务用例：

1、业务复杂度高，有5个以上的子模块（业务功能比较复杂）。

2、项目需要长期迭代开发和维护。

3、需求水平：公司已发展到一定规模，需求变化频繁，研发团队已达到10人左右。

4.性能等级：不需要苛刻响应时间的系统，如电子商务系统。

5、数据一致性：尽量避免分布式事务。

如果数据一致性不是太高，则可以保证最终的一致性。

顾名思义，微服务必须从两个方面来理解。

什么"微"

从狭义上讲，微型规模小，名声大"2Pizza 团队"这个解释解释很好（2pizza团队最早是由亚马逊ceobezos提出的，这意味着设计一个单一的服务，所有参与者从设计、开发、测试、运维加起来只需要2个披萨）。

什么"服务业"！

所谓服务，必须与系统不同，系统是一个相对较小的、独立的功能单元或一组服务，是用户能感知到的最小的一组功能。

微服务（也称为微服务体系结构）是一种体系结构风格，它将应用程序构建为以业务域为模型的小型自治服务集合。

微服务是一种新兴的软件架构，它将大型单个应用程序和服务拆分为数十个支持微服务。 微服务策略可以通过扩展单个组件而不是整个应用程序堆栈来满足服务级别协议，从而使工作更轻松; 对于较大的应用程序，添加更多用户意味着提供更大的 Elastic Compute Cloud （EC2） 实例，即使其中只有部分功能可以扩展。 最终结果是，企业用户只需为支持比微服务更多的 EC2 实例付费。

微服务可以在“自己的程序”中运行，并通过“轻量级设备”与基于HTTP的API进行通信。 关键是该服务可以在自己的程序中运行。 这使我们能够将服务暴露与微服务架构（在现有系统中分发 API）区分开来。

在服务公开中，许多服务可能会受到内部独立流程的约束。 如果这些服务中的任何一个需要添加某些功能，则必须缩小该过程。 在微服务架构中，只需将所需的功能添加到特定服务中，而不会影响整个流程架构。

自去年以来，微服务已被许多开发人员所接受，我们看到许多项目都在尝试微服务架构，结果令人鼓舞。 然而，微服务架构带来了独立部署、高扩展性和扩展性、开发语言自由选择、资源高效利用、故障隔离等优势，但也带来了分布式事务、服务间通信、监控、部署等新问题。

说到微服务架构，我们经常做的一件事就是把它和单体架构进行对比，单体架构有以下缺点：维护难、部署臃肿、弹性和可扩展性有限、阻碍团队和技术创新等; 微服务架构具有维护简单、独立部署、扩展性和扩展性高、开发语言自由选择等优点。

上图来自Martin Fowler的文章，揭示了生产力和复杂性之间的关系。 复杂度较低时，使用单体的生产力较高，当复杂度达到一定规模时，单体应用的生产力开始急剧下降，拆分为微服务是性价比高的。 因此，在业务场景之外，谈论架构绝对是流氓。

如果架构设计异常出色，如果不能在业务场景中实现，那只是一句空话。 因此，架构需要服务于业务，而架构设计对于不同的业务场景会有所不同，架构设计不必追求高大、简洁、美观的架构，如果能满足业务发展的需要，就是一个好的架构。 此外，一个好的架构并不完全是设计好的，而是随着业务量和请求量的增长而发展的。

微服务架构之所以被广泛认可，是因为它不适合业务可变性，而微服务架构可以不断演进，快速适应业务变化。 然而，与具有单体架构的大规模、严格定义的开发项目相比，微服务架构需要一个由许多小型服务组成的复杂生态系统。

有鉴于此，如果长期业务计划不需要微服务架构，或者团队没有一些实现微服务的基本条件，不建议盲目向微服务新兴架构领域迈进，或者先试入手，在团队中逐步实现微服务架构。