首先技术并没有好坏之分，只能说一种技术在特定场景会优于另一种技术。
首先uread优读（http://aiuread.com/）作为一个还处于起步阶段的团队，那么没办法造出像大企业他们那种自动化运维平台，真实情况是连用OpenStack来管理应用都是一种高难度活。
第一阶段，单体应用，纯人力部署
团队一开始，反正后端就一个系统，然后又是用git作为团队内部的协作工具，部署理所当然是直接每次发布新版本，直接执行git pull，然后执行一个封装好kill进程，重启进程的shell脚本，接着更新版本流程完成。
第二阶段，服务拆分，交互遇到问题
随着功能越来越多，后端前端的同学也越来越多，以前一个工程囊括整个项目的做法的弊端开始显露出来。首先，由于工程膨胀，要一位新来的同学看懂整个工程会变得非常困难，并且提交代码的时候冲突会非常严重。现在微服务不是很流行么，所以团队也考虑是不是拆开成微服务呢。
一开始，已经研发的部分也不可能推倒拆分。所以，决定新增的大功能拆成独立工程。当拆开独立项目的时候，第一个出现的问题并不是部署问题，因为多几个应用，部署工作量其实也不会是人力不能承受。
拆分应用之后，出现的主要问题是，这些独立的应用如何交互。也许你会说是不是设计不合理呀，微服务单向调用那会有什么问题。且慢，当你实践过，你就不会说就这么简单。
微服务交互，主要我们尝试过基于http协议的交互，对于耗时处理采用回调方式。由于业务原因，有大量耗时操作，所以一个功能就要写很多个微服务。
由于为了每位同学都只关注自己的模块，所以数据入库也是自己处理自己的部分，结果就是一个业务交互就需要4个微服务。
基于http协议交互，一个问题是，每一个微服务都有一个ip和端口。当我们的微服务数量越来越多的时候，配置里面的地址信息也越来越不好维护，特别涉及服务地址变动的时候。这个时候，基于消息中间件的微服务交互方式进入我们的研发之中。
第三阶段，基于消息中间件的微服务交互
当我们引入了rabbitmq这个消息中间件，代替了http请求通讯。我们再也不怕微服务地址变更这种问题，在微服务扩容的时候，我们也可以无缝处理。但是我们最后还是弃用了这种交互方式，为什么呢？因为我们忘记了我们只是一个小团队，引入越多的技术，对于我们经验不太丰富的同学来说，简直就是灾难。
那么，我们只能用回基于http的交互方式，但是微服务地址维护这个大问题就需要一个途径解决掉。
第四阶段，微服务基于sdk交互
这个时候，我们编写某个微服务的同学，就要提供调用该微服务的sdk，那么对于调用该服务的同学来说，只需要引入该sdk即可，无论微服务如何变，更新sdk即可（sdk的函数必须是兼容升级）。
第五阶段，服务发现系统
虽然，我们基于sdk来调用微服务，但是一个问题来了。我们微服务每一次扩容，就要更新sdk里面的地址。这个对于我们弹性部署来说是一个严重问题。
这个时候，sdk动态获取一个微服务真实地址就十分重要了。所以我们简单的造了一套系统，一个服务名字随机获取一个微服务真实地址。架构图如下：
第六阶段，自动化部署
微服务的交互这个最主要问题解决之后，免去人工执行shell脚本部署应用提上了日程。
原始阶段，把创建环境拉取代码封装成一个shell脚本。打包环境采用docker镜像，为什么用docker呢，因为docker打包环境写一个Dockerfile就成了，并且最新版的docker可以用docker swarm把容器分布到多台机器。
每次更新，手动执行shell工作量还是有点大，好在有git钩子，每一次某个分支提交代码后触发脚本自动部署。
第七阶段，应用日志问题
由于阶段六，我们应用存在docker里面，日志也在容器里面，并且分散在多台服务器。日志收集是一个问题，主流的ELK这一套还是同样的问题，太重了，引入对团队是一个负担。所以一个折中的办法，由于我们用的框架都有一个同一个错误捕捉函数，当我们捕抓到错误的时候，我们就把信息post到通知机器人钩子，这些程序会把信息发到我们的协同工作软件，所以我们会第一时间知道哪个请求触发了什么错误。
接下来
当然是要做弹性扩容了，只是当前还没有需要大规模扩容的场景，那就先不造这轮子。
