微服务的理想与现实
< 返回列表时间: 2020-05-27来源:OSCHINA
【围观】麒麟芯片遭打压成绝版,华为亿元投入又砸向了哪里?>>>
随着云原生微服务的日益火热,很多人都开始对微服务的相关知识内容感兴趣。本篇内容,旨在扫盲(意思是小白可入),希望能对大家有帮助。如有问题,欢迎大家一起讨论,共同学习进步。
01 微服务从哪里来?--- 服务架构的演进史
互联网初期, 2G还是个时髦词儿,人们的需求也很朴实,一个静态网站告诉大家我是谁、一个留言板让大家能够与我联系,就能满足信息传播和互相交流的需要。于是码农们给我们提供了这样一套解决方案: 界面+业务处理+数据处理 ,通过一个zip包就可完成所有的事情,这也就是服务架构的 单体架构时代 。

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

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

图片为作者原创
又过了几年,电商掀起了各个时节的线上大促活动,与之伴随而来的还有持续交付、灰度发布、服务限流、容错保护、链路跟踪、日志监控、弹性伸缩等等一大串需求,也还有程序员日益见秃的头顶和度数越来越深的眼镜。当运维压力已经赶不上业务的快速发展时, 微服务时代来临 。可以这样理解,微服务架构也是SOA架构分布式化的一种实现方式。它的优势在于小而治之、去中心化,但与之对应的问题是,你要管理越来越多的微服务。而如何进行微服务拆分和服务治理,是十分考验能力的试金石。
纵观前后,服务架构历次的迭代更新,都是围绕着用户如何节约成本和提升效率,来解决不断出现的新问题, 微服务就是服务架构演进史的产物之一 。
02 微服务是什么?

图片为作者原创
微服务最流行的定义是由 Martin Fowler 与 James Lewis 于 2014 年共同提出。引用老爷子们的说法: 微服务是架构层的一个概念,通过分解(业务单元),将项目拆解出 n 个单元,互相没有强依赖关系(解耦),自我准备需要的依赖条件,进而达到可以独立运行、独立部署,不再受环境与地点上的限制。 微服务架构风格是一种使用一套小服务来开发单个应用的一种方式,每个服务运行在自己的进程中,并使用轻量级机制通信,通常采用HTTP资源API这样轻量的机制来相互通信,这些服务围绕业务功能进行构建,并能够通过自动化部署机制来独立部署,这些服务使用不同编程语言实现,以及不同数据存储技术,并保持最低限度的集中式管理。

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

图片来源:InfoQ发布的2019架构和设计领域趋势报告
03 如何选?适合的才是最好的
在我们选择之前,先来看看有什么能够选的?
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)人和
如果要享受微服务带来的优势,就需要接受微服务带来的挑战。比如: 虽然微服务的服务边界限定,每个团队可以独立维护演进自己的服务,但是当服务扩展到几十个甚至上百个后,就需要考虑分布式带来的复杂性。 如果说不同服务可独立部署、独立扩展,那么维护不同版本和版本兼容就是需要面对的挑战。 如果说不同的服务可以采用不同的技术栈,只需按照约定好的通信协议即可完成交互,那么服务之间的认证/鉴权/证书管理,共享数据与分离数据后如何保持一致性等一系列复杂的问题等,就是需要面对的挑战。 ……
总之,使用微服务也是需要天时地利人和的,使用的过程也不要一蹴而就,服务治理是巨大的挑战。
你的业务适合微服务吗?我收集整理了几个最简单的问题以供快速自测:

04 微服务化的实施方法
简单来说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和产生公网流量费用。

入门示例参见: https:// docs.jdcloud.com/cn/jd- distributed-service-framework/gw_vpc
怎么样,微服务看上去是不是又没有那么抽象、那么难、那么抓狂了呢?!更多内容下次再分解。


欢迎点击“ 京东智联云 ”了解更多精彩内容!

热门排行