来源 | 京东智联云开发者

随着云原生微服务的日益火热，很多人都开始对微服务的相关知识内容感兴趣。本篇内容，旨在扫盲（意思是小白可入），希望能对大家有帮助。如有问题，欢迎大家一起讨论，共同学习进步。

微服务从哪里来？--- 服务架构的演进史

互联网初期， 2G还是个时髦词儿，人们的需求也很朴实，一个静态网站告诉大家我是谁、一个留言板让大家能够与我联系，就能满足信息传播和互相交流的需要。于是码农们给我们提供了这样一套解决方案：界面+业务处理+数据处理，通过一个zip包就可完成所有的事情，这也就是服务架构的单体架构时代。

图片为作者原创

随着3G的普及，越来越多的人们可以通过PC上网了，此时BBS、门户咨询网站的出现开始吸引着大量观众。当漂亮的交互更能抓人眼球、有趣的信息瞬间引爆千万用户在线围观时，“并发“问题产生了，于是码农们加班奋战，将系统分为前端和后端，通过拆分出可复用的中间件，来提升业务处理能力、解决并发问题，这便是分层架构时代的到来。

图片为作者原创

后来，互联网进入微博时代，几乎网民都有Blog，打开手机就刷weibo。而此时的分层架构面对更复杂服务要求时，在应用扩展、服务调用、扩容等方面都越发桎梏，于是服务架构走进了面向服务的架构（SOA）时代。SOA网上说的很多，这里列举几个关键词：中心化的服务治理， ESB（企业服务总线）中心化、服务之间通过精确定义的接口进行通讯、耦合度更低、扩展性更高、维护成本较高。

图片为作者原创

又过了几年，电商掀起了各个时节的线上大促活动，与之伴随而来的还有持续交付、灰度发布、服务限流、容错保护、链路跟踪、日志监控、弹性伸缩等等一大串需求，也还有程序员日益见秃的头顶和度数越来越深的眼镜。当运维压力已经赶不上业务的快速发展时，微服务时代来临。可以这样理解，微服务架构也是SOA架构分布式化的一种实现方式。它的优势在于小而治之、去中心化，但与之对应的问题是，你要管理越来越多的微服务。而如何进行微服务拆分和服务治理，是十分考验能力的试金石。

纵观前后，服务架构历次的迭代更新，都是围绕着用户如何节约成本和提升效率，来解决不断出现的新问题，微服务就是服务架构演进史的产物之一。

微服务是什么？

图片为作者原创

微服务最流行的定义是由 Martin Fowler 与 James Lewis 于 2014 年共同提出。引用老爷子们的说法：

微服务是架构层的一个概念，通过分解（业务单元），将项目拆解出 n 个单元，互相没有强依赖关系（解耦），自我准备需要的依赖条件，进而达到可以独立运行、独立部署，不再受环境与地点上的限制。
微服务架构风格是一种使用一套小服务来开发单个应用的一种方式，每个服务运行在自己的进程中，并使用轻量级机制通信，通常采用HTTP资源API这样轻量的机制来相互通信，这些服务围绕业务功能进行构建，并能够通过自动化部署机制来独立部署，这些服务使用不同编程语言实现，以及不同数据存储技术，并保持最低限度的集中式管理。

根据InfoQ发布的2019架构和设计领域趋势报告显示，微服务架构已经走过了盲目追捧阶段，开始逐渐走向成熟，走向切实可落地阶段。

图片来源：InfoQ发布的2019架构和设计领域趋势报告

如何选？适合的才是最好的

在我们选择之前，先来看看有什么能够选的？

1、微服务框架的分类

目前市场上已经出现的微服务框架非常多，他们各有所长。常见的微服务框架都有哪些呢?

如果从常见微服务框架形式分类来看，目前主要分为4类。

组件类——用户可以按需加载使用。常见的有Kubernetes、Eureka/Consul/etcd、ZipKin/Jagger等。
集成类——集成类的优势在于简化了分布式系统基础设施的开发，提供服务发现注册、配置中心、消息总线、负载均衡、数据监控等内容。常见的有Spring Cloud、Dubbo等。
网格类——常见的有Istio、Linkerd、Kong Mesh等。
无服务类——目前主要是大厂在使用，常见的有Knative、OpenFaaS、Kubeless、Fission等。

如果按照目前的主流生态体系来看，目前有三大生态体系：

Spring Cloud家族（https://www.springcloud.cc/）
Dubbo家族（http://dubbo.apache.org/en-us/ ）
云原生家族（https://www.cncf.io/）

这里特提供了官方地址供大家学习，本文不再详细展开讨论，每一个家族都需要熬夜掉一把头发，潜心实践和学习才能掌握。

总而言之，微服务的核心是服务治理，而服务治理就需要好的微服务框架，要不然微服务化可能是灾难！但做为用户，选择适合自己实际情况的才是最好的。

2、选择适合自己的微服务框架

那么我们该如何选择微服务框架呢？依赖于业务特点和技术能力。先选定方向，再研究技术细节。下面关于方向选择的思路供各位参考：

如果你的业务模块与服务治理是整合在一起的，依托特定开发语言和开发框架，通过配置来调整规则和策略，依赖业务上线对服务治理进行功能升级，那么你可能比较适合集成方式进行服务治理。你可以在Spring Cloud、Dubbo生态中去选择合适自己的方式。

如果你的业务模块与服务治理是分开的，与开发语言无关、与开发框架无关，通过动态调整来配置运行时各种规则和策略，服务治理功能升级独立于业务模块，那么你可能比较适合服务网格的方式进行服务治理。你可以在云原生家族中去选择合适自己的方式，比如尝试下Istio。

3、什么时候引入微服务？

微服务不是万能的，换句话说，微服务未见得适合于你。

1）天时

在业务运行初期，如果你是单业务系统架构，如果业务量不大且复杂性不高，如果你追求快速响应、开拓服务、节省成本、提高效率，那么你可能真的用不着微服务。比如你如果只是要用CMS做一套公司网站，那真的可能不用微服务这把牛刀。当随着你的业务进入扩展期，你的系统架构开始走向面向服务架构，业务不断扩大，业务系统复杂性不断提高，但效率在不断下降，那么这个时候你可以开始考虑业务拆分、使用微服务了。

2）地利

如果要进行微服务改造，还需要具备一定的资源条件，如物理机资源、网络资源。举个例子：假设一个电商平台，现状如图。如果业务框架不那么复杂则可考虑不用微服务架构。而如果需要进行微服务改造，那么至少需要准备规划好如下资源：

硬件资源：主机/容器、数据库
软件资源：注册中心、拆分的服务、负载均衡、网关、缓存、监控软件
人力资源：至少需要架构师构建微服务、前端、后端、测试，其中运维的角色可以由研发+微服务平台代替。

3）人和

如果要享受微服务带来的优势，就需要接受微服务带来的挑战。比如：

虽然微服务的服务边界限定，每个团队可以独立维护演进自己的服务，但是当服务扩展到几十个甚至上百个后，就需要考虑分布式带来的复杂性。
如果说不同服务可独立部署、独立扩展，那么维护不同版本和版本兼容就是需要面对的挑战。
如果说不同的服务可以采用不同的技术栈，只需按照约定好的通信协议即可完成交互，那么服务之间的认证/鉴权/证书管理，共享数据与分离数据后如何保持一致性等一系列复杂的问题等，就是需要面对的挑战。
……

总之，使用微服务也是需要天时地利人和的，使用的过程也不要一蹴而就，服务治理是巨大的挑战。

你的业务适合微服务吗？我收集整理了几个最简单的问题以供快速自测：

微服务化的实施方法

简单来说4步走：

其实每一步都有可能会有“坑”，这里面都是学问，都可独立成章。因此，本文不详细展开，以后再写相关内容文章详谈。

但是，Demo可以快速帮我们一探究竟，这里我选择了京东智联云的微服务平台来做体验。

为啥是云上公有云产品？

因为微服务的体系太复杂庞大了，如果你自建，1个人搞不定1个团队的工作内容。

还因为在“云”上是托管服务，少运维，所见即所得组件多，开源、多可用区、上手够简单够快、学习和使用成本低呀。

简单总结下我的学习路径：

1、体验“云”上高可用注册中心

如果您已有成熟的微服务项目，目前正在上云过程中，希望享受 “云” 带来的注册中心多可用区部署、最大程度的保证集群高可用的能力。那么可以直接使用微服务平台的命名空间注册中心功能。目前JDSF支持的微服务框架包含：SpringCloud、Dubbo、JSF。使用大致步骤如下：

入门示例参见：https://docs.jdcloud.com/cn/jd-distributed-service-framework/basic-example 。

2、体验调用链分析服务便捷定位性能瓶颈

如果您已有成熟的微服务项目，目前正在上云过程中，希望通过 “云” 计算能力，更加便捷全面掌握服务间调用关系、精准发现系统的瓶颈和隐患的服务、减少运维投入，那么可以直接使用微服务平台的调用链分析服务。目前支持协议：ZipKin、Thrift、HTTP。

入门示例参见：https://docs.jdcloud.com/cn/jd-distributed-service-framework/basic-example 。

3、体验应用部署

如果您已经使用云上JDSF服务，还可以使用JDSF平台提供的成熟、灵活的部署方案发布微服务应用。目前应用类型支持：云主机应用、K8S应用。

入门示例参见：https://docs.jdcloud.com/cn/jd-distributed-service-framework/demo-deploy-k8s

4、体验开放服务给客户使用

如果需要开放服务给你的用户使用，假如你已经使用了微服务平台的注册中心服务，微服务网关可以在调用时自动完成服务发现、负载均衡，无需再使用其他负载均衡或网关服务。假如你的服务已经通过其他方式在内网发布到了负载均衡服务上，也可以通过微服务网关实现与API网关的无缝对接，避免公网暴露，不再需要申请公网IP和产生公网流量费用。