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

随着数字经济的不断发展，企业面临着更加多样化、敏捷化的新时代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的基本运行原理：

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

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

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

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

最后一步，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）。
• 容错。
• 快速演化。

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