微服务实战之春云与刀客（一）—— 微服务开篇

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

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

什么是微服务（Microservice）

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

微服务的特点

从服务发展历程来看，微服务分布点较多，互相可以调用。

所以微服务有如下特点：
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

微服务不是银弹

说完优点，也该谈谈缺点了。

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

微服务框架选型

说完，马上就动手了，采用什么框架呢？
在淘宝的时候，可以使用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会有重复的嫌疑。所以实际实施的过程中就得考虑清楚了。