本篇文章将带您系统了解关于企业级微服务治理与开发的关键概念及选型指南，希望能为您的企业级现代化应用建设提供启发。

微服务是应用现代化趋势下的必然选择

随着数字经济的不断发展，企业面临着更加多样化、敏捷化的新时代IT需求。

· 用户行为的变化：业务应用的用户访问不可预估，突发性访问增多，存在临时热点事件或大促期间等不可控业务高峰期。

· 业务模式的变化：所有业务访问都是通过互联网渠道，包括Web、手机App、微信小程序等。

· 业务系统开发的变化：应用再也不像以前半年或一年进行规划，随时会有需求变化，两周一个迭代成为常态。业务应用交付周期短，质量要求高。

· 运维模式的变化：要求全天候值守，在线升级和快速响应，不同团队特别是外包团队使用不同的技术栈，无法统一管控。

因此，评估一家企业是否需要采用微服务架构，往往考察这五大关键条件：数据量和业务复杂度，团队规模，应对业务流量变化，是否需求足够的容错容灾，以及功能重复度和差错成本。

在日益激烈的数字化竞争下，企业必须更快地拥抱市场变化、随时响应新的用户需求，比对手更迅速地将产品推向市场。

微服务作为加速企业提升敏捷创新能力的重要抓手，能够帮助企业快速实现独立更新和部署应用，快速应对市场变化，逐渐成为企业加速应用现代化的必然选择。

微服务架构怎么选？

· Dubbo

Dubbo是比较早期的一款微服务架构，可以使得应用通过高性能的 RPC 实现服务的输出和输入功能，和Spring框架无缝集成。

优点是RPC长连接+NIO，性能更高；但协议的局限性，会限制生态发展和兼容性。

· Spring Cloud

Spring Cloud是基于Spring Boot的一整套实现微服务的框架，提供了微服务开发所需的配置管理、服务发现、断路器、智能路由、微代理、控制总线等组件。Spring Cloud包含了非常多的子框架，其中，Spring Cloud Netflix是其中一套框架，由Netflix开发后来又并入Spring Cloud大家庭，它主要提供的模块包括：服务发现、断路器和监控、智能路由、客户端负载均衡等。

Spring Cloud拥有更成熟的Spring社区生态，更多成熟的企业应用案例；但也存在一定不足，比如跨语言平台问题、微服务治理对代码侵入性较强。

· Istio

Istio 是当前Service Mesh形态上比较热门的实现方案，能够和K8s深度结合，更快速、更便捷地实现服务治理。Istio 提供了一种简单的方法，来创建一个提供负载均衡、服务间认证、监控等的服务网络，且不需要对服务代码进行任何更改。通过在整个环境中部署专门的 sidecar 代理服务，来拦截微服务间的所有网络通信，整个配置和管理通过 Istio的控制面板来做。

作为新一代的微服务架构，它的微服务治理与开发更彻底解耦，适应场景更广泛，很多企业都正在逐步从Spring Cloud向 Service Mesh过渡；但也正是因为技术比较新，企业自研需要一定的学习成本，打破传统IT运维/开发壁垒，考虑引入专业的技术厂商则能够完美地解决这一问题。

上图为Istio的基本运行原理：

1、当用户向 Kubernetes 提交一份新的配置，首先会触发 galley 注册在 kubernetes 中的webhook，webhook 会检查配置是否合法，如图中的步骤1。

2、若配置无法通过校验，则 kubernetes将拒绝用户提交的配置，并给出相应的错误信息。如图步骤2。

3、当配置通过校验后，通过 kubernetes 的通知机制，galley得到配置变更信息

4、Galley 将变更的配置/服务信息转换为 MCP 的格式通过 MCP 协议推送给pilot，如图步骤4。

5、最后一步，pilot 通过 xDS 协议向数据平面推送变更的配置。

以上为当前常见的微服务架构，那么企业实际改造时应该怎么做呢？我们建议：

· 不同类型的应用均可以通过微服务能力进化到现代化应用。

· 需要为传统应用提供一条稳妥的转型路径

· 需要为SpringCloud应用提供一条贴合云原生的、无需大规模适配的转型路径。

微服务架构如何设计？

首先从微服务的定义来看，微服务是一起合作的独立小服务单元，可以同步异步调用，也可以独立拆分、独立部署、独立升级，后端中间件、存储资源、数据库等也是独立的，最佳实践是每个微服务都有自己的database，真正意义上实现微服务应用解耦。

接下来，我们从微服务的必备基础理论，也是企业进行微服务所需遵循的一大原则——康威定律来看：

组织形式等同系统设计。设计系统的组织，其产生的设计等同于组织之内、组织之间的沟通结构。

第一定律：Communication dictates design（组织沟通方式会通过系统设计表达出来）。

人与人的沟通是非常复杂的，一个人的沟通精力是有限的，所以当问题太复杂需要很多人解决的时候，我们需要做拆分组织来达成对沟通效率的管理。在团队内部进行频繁的、细粒度的沟通。对于团队外部，定义好接口，契约，只进行粗粒度的沟通。这样可以降低沟通成本，同时也符合高内聚，低耦合原则。

第二定律：There is never enough time to do something right, but there is always enough time to do it over（时间再多一件事情也不可能做的完美，但总有时间做完一件事情）。

复杂的系统需要通过容错弹性的方式持续优化，不要指望一个大而全的设计或架构，好的架构和设计都是慢慢迭代出来的。因此企业需要拥抱变化，解决当下，先完成一个一个小目标。

第三定律：There is a homomorphism from the linear graph of a system to the linear graph of its design organization（线型系统和线型组织架构间有潜在的异质同态特性）。

你想要什么样的系统，就搭建什么样的团队，反之亦然。

第四定律：The structures of large systems tend to disintegrate during development, qualitatively more so than with small systems（大的系统组织总是比小系统更倾向于分解）。

一个大的组织因为沟通成本/管理问题，总会被拆分成一个个小团队（2 pizza team）。

具体来说，企业在进行微服务架构改造时，可以遵循以下标准：

· 分布式服务组成的系统。

· 按照业务而不是技术来划分组织。

· 做有生命的产品而不是项目。

· 去中心化。

· 自动化运维（DevOps）。

· 容错。

· 快速演化。

同时，根据企业的自身组织架构情况和业务情况进行针对性规划设计。

点此查看微服务治理与开发培训视频。

即刻开始微服务架构改造

点击此处立即定制属于您的微服务解决方案。

上一篇：企业应用现代化实用教程 | 如何快、准、狠地进行应用容器化改造？

下一篇：企业应用现代化实用教程 | IT架构师必读的DevOps落地行动指南