以下内容根据演讲PPT以及现场分享整理而成。
今天主要分享的是我们在实践微服务架构或者容器架构过程中踩过的坑，对于致力在容器技术方面进行探索的同学会有很大帮助。本次将站在整体的角度，分享如何去运维整个线上系统，如何看待整个微服务的架构、微服务能带来什么帮助以及微服务又有哪些缺点，还有重要的一点就是微服务架构如何去落地实施。虽然阿里云这样的服务商为我们做了大量的工作，但是将微服务架构真正地落地实施还需要做很多的工作。而对于任何技术而言，都是存在优缺点的，微服务架构也不是救世的良药。
一、学霸君的发展路径
学霸君从成立到现在不到4年的时间，在这期间推出了拍照答疑和实时答疑，这些都是在整个在线教育领域的重磅产品。
其实在快速发展的过程中，公司业务往往会急速扩张并且业务架构也会逐渐复杂化，此时运维就是一个比较头疼的事情。在早期，为了业务能尽快上线，运维会有很多的退让，因为此时的最高优先级是让业务能够尽快上线，不太会关注标准化和安全性。这就导致后期业务规模越来越大的时候，维护的难度将会呈现指数级递增。这时就不得不考虑运维自动化了，但是传统方式中想要实现运维自动化就需要一个团队来开发一个平台或者系统，而在这方面花费的人力和物力对于中小企业或者处于发展阶段的创业公司而言都是比较大的开销。所以我们希望能借助第三方服务和架构体系完成自动化运维系统的构建。
微服务的架构方式比较适合的人群是：
- 对微服务架构向往，希望有所实践的公司。
- 对微服务和docker有一些了解，希望获得实际生产实践经验的同行。
- 希望借助第三方服务，最大化优化运维效率的中小企业。
二、被宣传的微服务
接下来先聊一聊业界对于微服务宣传的优点。下图是几种架构的对比，对于早期的单体应用而言就像这盘意大利面一样，所有的功能模块都是混在一起的。再进化一些就是类似于SOA的架构，它解耦了一定的服务化，相当于可以将一个大应用拆分成一片一片的应用，但是每一个片对于整体的连接还是非常紧密的，想要对于某些模块进行独立的部署而不影响其他的模块也是比较困难的。而微服务的架构在此基础之上做了更进一步的推进，就是一个应用可以被拆分成多个服务模块，这些服务模块都是独立部署独立维护的，每次更新都不会对整体业务有所影响，而且是基于共享的通讯机制的。
其实微服务更大的优点就是：其部署方式和扩容方式与传统的单体应用相比也有很大的提升，它将单体应用中的服务进行了更细粒度的拆分，在部署或者扩容的时候并不用对整个应用进行整体扩容，只需要将应用中遇到性能瓶颈的模块进行扩容就可以了，这样的更细粒度的扩容方式可以节省资源。
微服务、docker以及Devops的区别
- 微服务：是一种架构思想，目的是有效的拆分应用，实现敏捷开发和部署；
- docker：为微服务化架构的实现提供了技术基础；
- Devops：是一种重视软件开发、运维和质量保证之间沟通合作的文化、运动或惯例；
三、运维眼中的微服务
之前分享了很多微服务架构的优点，站在真正使用微服务架构进行运维的人员的角度，到底微服务架构能够解决我们什么问题呢？
作为运维人员在使用微服务架构的时候需要思考几个问题：
- 如何贯彻Devops流程？微服务将减小不同环境之间的差异，流水线式的一体化上线。
- 如何实现持续集成/交付？微服务将大幅缩短服务上线的时间，并减少人为的干预。
- 如何快速定位并解决故障？微服务将使服务链路清晰可感知，可以快速定位故障的原因所在。
- 如何实现细粒度监控？微服务将提供链路监控、服务监控等，可以真切反应业务运行状态。
- 如何实现高可用系统架构？微服务采取服务分布式部署，并可快速的进行灾备切换。
- 如何有效提高基础设施资源利用率？通过微服务架构可以及时掌握集群的容量状态，并可以实现自动扩缩容。
四、如何落地微服务
对于发展中的创业公司而言，除了以上六点，如何将微服务架构落地实现也是值得思考的一件事情。当我们决定向微服务转型的时候也冒了一定风险，因为当时只能抽出两个人来做基于容器和微服务架构的新项目，而且时间只有一个半月。这时候就需要面对很多问题，首先就是要进行微架构选型，到底是选用什么方式，是利用开源软件进行二次开发还是借用一些第三方比较成熟的技术方案来实施？
为什么选在新项目上新的架构的尝试呢？大家都知道对于已经成熟的项目不管是对其进行改动还是推进都是比较困难的，其次微服务架构作为比较新的架构技术，在生产环境下真正能将微服务架构运用的很好的案例还不是很多，我们认为新项目可以容忍一定程度地踩坑，所以在新项目上实施微服务架构。
这是当时的项目的架构图，这样一个简单的应用其实涉及到了9个服务模块，而且这还只是项目初期。项目涉及到了许多的开发语言和框架，这样对于开发人员而言非常方便，可以选择自己熟悉的语言，但是对于维护人员而言简直是噩梦，因为需要维护的东西实在太多。
这样的架构如何在生产环境下真正地运行呢？这也是整个微服务架构和容器化需要考虑的问题，无论是自己进行开发还是使用开源软件进行二次开发都需要考虑。
下图是基于docker的微服务架构技术栈。最上层是应用层；下一层是接入层，涉及到负载均衡的高可用和稳定性；再下层的服务层就是微服务的双方如何去注册和发现对方，以及如何进行通信以及部署上线的灰度发布；再下一层更多的是容器级别的内容，容器集群的正常运转是业务正常运行的保证，这一层面同时涉及到代码库以及容器镜像的管理；最后一个层面涉及的就是阿里云提供的云服务以及一些私有云等。
这么多的东西都需要自己做么？虽然目前有很多的开源软件可以使用，但是基于开源软件进行二次开发还是比较困难的。所以我们选择了使用阿里云的比较成熟的技术方案。
当时我们对比了多家服务提供商，包括阿里云、AWS和第三方的Pass平台。相比之下，阿里云和AWS拥有一定的优势，但是AWS的容器服务在国内无法使用，所以我们最终选择了阿里云的容器方案。
接下来谈一下在容器技术方案中需要关注的几点。
持续集成和交付
如果容器方案中支持良好的持续集成和交付将大大缩短应用上线的时间。同时我们对接了自己的源代码管理系统，对于代码的管控更加安全，代码可以直接拉到阿里云上构建的Jenkins的系统，然后利用通用型的构建方式将代码构建成镜像，直接推倒阿里云的镜像仓库。这样对于镜像的管理都是由阿里云提供的，开发者不需要关心太多的细节。而且对于同样一份镜像和同样一个服务，可以在三个环境下运行，而且不会存在差异。
配置
一些配置可能会经常变动，而另一些则不会。所以可以将配置进行分类：业务级的配置和运维级的配置。业务级的配置不会因为环境而变化，可以看做是代码的一部分，而运维级的配置则会依据环境变化，对于配置分离能简化运维成本，避免污染repo。
日志
下图是阿里云提供的日志系统框架。这个日志系统可以对接后端，进行很多的数据处理和分析。
日志一般分为debug日志和性能分析日志。
五、微服务不是救世良药
微服务架构并不能解决所有问题，它也有很多的缺点。
- 分布性系统天生的复杂性，如网络延迟、容错性、不可靠的网络、异步机制等
- 运维开销及成本增加，一个单体应用被拆分部署成十几个服务，增大了运维的压力。
- 隐式接口及接口匹配问题，不同组件间协作需要统一可管理的接口。
- 代码重复，为了尽量实现松耦合，相同功能的底层功能会在不同服务内多次实现。
- 异步机制，微服务往往使用异步编程、消息与并行机制，会引入新的故障点。
- 其他的像不可变基础设施、管理难度、微服务架构的推进等。