微服务实战之春云与刀客(一)—— 微服务开篇

  1. 云栖社区>
  2. 博客>
  3. 正文

微服务实战之春云与刀客(一)—— 微服务开篇

coolma2000 2017-12-14 18:48:45 浏览1760
展开阅读全文

春云即spring cloud ,刀客即docker,这种翻译似乎比较好玩!
这里是春云与刀客不得不说的故事,不会讲太多的入门,更多的是实战和一些规范,以及通过春云和刀客如何简化微服务开发,这些在一些书籍都是没有介绍的。

本篇讲微服务概念和技术选型。

什么是微服务(Microservice)

通常别人问这个问题都不知道如何回答。其实很简单,按字面拆解就是,微服务就是:
微小的服务。
什么是微小?就是单一职责
什么是单一职责?就是一个服务只干一类事情,多的事情我不干。我这个服务只管怎么按头,不管捏脚。
所以暂且给出一个定义:以单一职责划分功能模块组件,通过组件间通信完成复杂业务系统搭建的服务体系

微服务的特点

从服务发展历程来看,微服务分布点较多,互相可以调用。
image
所以微服务有如下特点:
1)根据业务模块划分服务种类。
按业务拆分服务,这是“水平拆分”;在技术层面的“前后分离”,属于“垂直拆分”;横纵一起切,就把单一的应用拆分成网状的小块应用,这是微服务中“微”思想的体现。

2)每个服务可以独立部署并且互相隔离。
独立部署与互相隔离,这点充分体现了“我为人人、人人为我”的设计理念,这是微服务中「服务」思想的体现。

3)通过轻量的 API 调用服务。
关于轻量 API,微服务本身是推荐使用轻量的通讯协议和简单的数据结构,实际上,实施环节通常采用的都是 http+json 的方式。

4)服务需要保证良好的高可用性。

微服务的优点

最大优点就是:人员分工明确,少些扯淡,提高工作效率。
具体理论基础可以看看康威定律和人月神话。
其中有这么个公式:沟通成本 = n(n-1)/2
5个人的项目组,需要沟通的渠道是 5*(5–1)/2 = 10
50个人的项目组,需要沟通的渠道是50*(50–1)/2 = 1,225

微服务不是银弹

说完优点,也该谈谈缺点了。
image

但不要怕,搞技术的就是要跨过这些大山,狠踩这些坑。

微服务框架选型

说完,马上就动手了,采用什么框架呢?
在淘宝的时候,可以使用HSF服务框架,到了市面上,国内用的比较多的是dubbo。dubbo是一个分布式服务框架,底层NIO基于netty框架,可惜在阿里内部一山不能容两虎,dubbo被废了。HSF经过多年逐渐优化,性能会更好,但也肯定跟内部各种中间件绑得太死,没法剥离给外头用;而dubbo产品化比较好,拿到外头好部署,市场很受欢迎,但好几年不更新了。然而,阿里云在集成各种第三方产品工具的时候,又瞄上了dubbo,能带来收益的东西肯定要用,所以在17年快年底的时候GitHub有有新版本的dubbo了。

可惜,这时我已经瞄上了春云了。首选,有哪个用java的互联网不用spring的?而Spring Cloud作为spring家族的后续重量级产品肯定也是越来越好的,肯定是以后技术的一个趋势,有现成的全家桶为何不用?
唯一担忧就是,Spring Cloud是用http方式的,比起RPC方式的性能差。其实这层不必担心,一是spring cloud也是利用连接池的,不是每次请求都重新连接的,而且有人做过实验,系统大都消耗在处理代码逻辑、访问数据库资源这些上面,而数据传输影响很小。二是RESTFUL API已经越来越普遍了。

docker swarm

说到微服务,就不能不提docker,而用docker,我们就要用最好的docker swarm集群。正好我们使用的时候,docker swarm已经比较稳定和强大了。我还是不明白,那docker swarm能干啥?
1)你以前是一个点一个点地run docker,现在swarm可以一次性跑多个点,哪天服务器压力太大,2个点不够了,你执行一个“docker service scale 服务名=5”命令马上就扩大到了5个点。
2)我的docker部署在多台物理机器的,它们直接怎么通信呢,哦,有个docker原厂工程师在github上推出了pipework工具,很牛逼,在此基础上可以实现docker直接通信,然后我去看了下各种网卡和ip地址操作命令,结果一脸的懵逼。然后还有其他各种方案的,弄得也很复杂,反正我也不懂。最后,还有一种成熟的用得比较广泛的方案,就是google的Kubernetes编排技术,我也没亲手试过,只是听说配置也有些复杂。docker swarm就是参考Kubernetes弄的,但因为swarm是原生支持docker的,所以使用上会更简单,所以我选择了swarm。
不过事情没有绝对,10 月 17 日,Docker 在丹麦哥本哈根举行的 DockerCon 大会上宣布,将扩大其 Docker 平台并选择积极拥抱容器编排对手 Kubernetes。这意味着 Docker 客户及开发人员将可以选择同时使用 Kubernetes 与 Docker Swarm 进行容器工作负载的编排。
这些都是后话了,当前选择docker swarm没毛病。

docker的野心很大,docker swarm已经包含了一套自己得微服务理念(例如内含注册中心), 一些地方跟spring cloud会有重复的嫌疑。所以实际实施的过程中就得考虑清楚了。

网友评论

登录后评论
0/500
评论
coolma2000
+ 关注