.Net微服务实战之DevOps篇

技术只是基础

　　该系列的两篇文章《.Net微服务实战之技术选型篇》和《.Net微服务实战之技术架构分层篇》都是以技术角度出发描述微服务架构的实施。

　　如果技术选型篇叙述的是工具，那么架构分层篇讲的就是技巧，而本篇要讨论的就是原则。一直以来我会给身边向我探讨问题的人灌输一种理念，没有什么技术银弹，因为我们做的是软件工程，提供的是问题相应的解决方案，不同类型问题的解决方案是存在着本质上的差异。

　　继续提供之前的源码：https://github.com/SkyChenSky/Sikiro

PS：该篇文章与.Net无关，其实主要是沿用前面两篇文章的命名，此外我认为DevOps不是简单的工具使用，应从软件工程角度进行出发。

什么才是优秀的架构设计？

　　曾经有好几个同行问过我同一个问题：什么才是优秀的架构设计？我一直信奉着两句话和一个定律：

• 架构服务于业务，技术服务于架构
• 康威定律（简单理解成组织架构的设计等同于系统架构的设计）

架构设计其实就是一种方案的取舍，在有限的资源里(包括但不限人力、时间)能让团队顺利的实施技术，同时满足业务规模的需要，我认为可以称之为优秀的架构设计，简单来说两个字合适

架构核心要素

　　核心的主要5大：性能、可用性、伸缩性、扩展性、安全性。

　　而我们所讨论的微服务，选择了扩展性，牺牲了可用性、性能，扩展性的目的就是为了快速响应需求变化、降低系统耦合度、提高系统模块的复用度。而微服务的调用是通过跨进程的网络通信的，跟进程内方法调用比无疑是慢了一个单位；原本单服务99.99%高可用，假如现在三个服务就是99.99%*99.99%*99.99%=99.97%。

　　当然我们可以在基于微服务的通过引入其他技术提高可用性、伸缩性和安全，但是确保无疑是牺牲了性能，除了性能还会在团队开发效率与运维复杂度上会受到影响。由此可见，没有万能技术手段，而架构其实在取舍。

　　引入一种技术必定带新的技术问题这是个必然结果，刚提到团队开发效率与运维复杂度会受到影响，那是否有办法缓解甚至解决并提高呢？既然涉及到团队、流程这些关键字那么就应该向软件工程方向寻找方案，合适架构实施还需要合适的开发模式进行支撑的，而风靡全球的DevOps就是不二之选。

软件工程

　　在行业盛传的一条公式：软件 = 软件工程 程序，可想而知软件工程的占据多么重要的比重。那么什么是软件工程？百度是这么解释的：

　　软件工程是研究和应用如何以系统性的、规范化的、可定量的过程化方法去开发和维护软件，以及如何把经过时间考验而证明正确的管理技术和当前能够得到的最好的技术方法结合起来的学科。它涉及到程序设计语言、数据库、软件开发工具、系统平台、标准、设计模式等方面。

　　我自己重新总结了一个软件工程的通俗描述，通过多人协作、有目标、有步骤、有计划的并使用科学方法论指导开发与维护程序的这个过程。也可以用一条公式表达：软件工程 = 工具 流程 模式。

软件危机

　　软件工程的出现目的是为了解决软件危机的。软件危机其实是当时落后的软件生产方式无法满足迅速增长的计算机软件需求，从而导致软件开发与维护过程中出现一列的严重问题的现象。那么三次软件危机是什么呢？我整理了个表格（详细可以自行百度阅读）

　　由上可见，软件的快速发展直接促使了软件工程上的进步，新的工具、新的开发与设计模式，新的协作流程也随之而生。

开发模式的发展

　　我工作多年经历了多家公司，所经历的有三种开发模式，瀑布、敏捷、DevOps。那么这三种主流的开发模式也对应着三个发展阶段：

瀑布开发模式

　　瀑布开发模式是在第一次软件危机1970时Winston Royce博士提出来。其思想是把项目过程划分为主要的六个阶段：需求收集、需求分析、软件设计、程序编码、软件测试、运行维护。团队划分也通过岗位职责进行划分：产品团队、开发团队、测试团队、运维团队。到目前为止该开发模式仍然用到做项目制的开发团队。

　　那么其优点与劣势也很明显，优点是计划明确，职责清晰，按部就班的完成就好。缺点是周期容易拖得太长，不容易调整变更，每个人只为自己职责范围内的负责，跨部门沟通成本大（这就是为什么我在图里画了两堵墙的原因）。我自己呆过一个瀑布模式的团队，在项目立项后就会被项目经理调动资源成为团队，而开发人员只会在这一次批次负责编码与修改测试反馈的问题，基本上上线后的问题跟你无关（除非紧急严重的），其他的BUG也许是下一个批次的另外一个开发人员帮你填。

敏捷开发模式

　　准确的说敏捷开发是一种价值观和原则的体现，2001年17位IT大佬想把瀑布发模式这种重量级的开发过程替换成一种更加轻量级，可惜大家都没有达成统一意见因此把各自都认同的观念整理出来成为敏捷宣言。

　　敏捷开发其实把产品、开发、测试三种岗位职责的人紧密的联系了起来，由原来长周期的大目标拆解成了一个个短周期的小目标。他之所以快，不是因为写代码快了，而是节省了很多不必要的前置条件与返工，同时小步快跑的交付也可以提高团队的士气，一个长周期项目那枯燥、乏味、痛苦的过程，谁试谁知道。

　　举个例子，大家都是为公司的同个产品努力，没有什么合同谈判可言，只要需求要求相互了解清楚并且可行就可以开干了。写详细设计文档的时间，还不如花时间多沟通下需求的核心点，想办法设计得更容易满足需求。短周期的交付后，产品与客户就可以及时的查看交付效果并相应的优化与调整。（快速响应并不代表随时随地接受变更响应，可以统一归到下一个迭代周期，我不赞同拍拍脑袋的变更，自己都没清楚的功能怎么说服客户使用？）

　　敏捷开发的最大好处之一就是短周期的持续交付，这样方式能在现阶段的互联网行业得到更快速的响应与市场的抢占，同时能很好的进行技术改进与试错。但是这种”野蛮的“方式会让开发团队与运维团队形成一条鸿沟，而鸿沟的形成主要原因是运维团队希望软件的运作是可靠的，所以他们对资源的变动、新技术的使用尤为的小心、谨慎。

　　我曾经呆过一个敏捷开发团队，生产出了问题运维团队会自行去修改配置，当然会越改越错了，而且一天发布次数多了，就会起争执。

DevOps

　　DevOps可以看过是敏捷的扩展与延申，它的出现就是为了解决开发团队与运维团队的那条鸿沟，只要存在人工处理的方式担心的问题总会出现，同一段程序无论执行多少次相同输入的输出总是一致的，但是人的处理却不能保证，那么使用自动化改善协作的过程，鸿沟自然就跨越了，。那么开发团队与运维团队就可以为相同的目标与方向而努力。而组织架构也将演变成如下：

　　从上图也与开头的康威定律做了一个很好的呼应。

我是如何实施DevOps的？

技术

　　这个角度是大家最乐意去关注的，在我们团队主要使用了以下技术，脚本什么的我就不花时间贴出来了，在我看来工具的使用，只要花点时间就能解决。

　　原本代码检查想引入SonarQube代替人工检查 Reshaper，可惜于服务器资源不足。

　　对于一般的团队，我建议优先从Gitlab Jenkins搭建好完成CI/CD，其次把日志系统给完善起来，这两者完成得越早，给团队带来的收益就越高，后续才会有更多的时间来完善整套技术体系，这是一个良性的循环。

人

　　人延申出的就是团队与文化，经过上面的讲解大家都意识到软件工程就是一样多人协作的工作，只有团队目标一致，共同负责承担团队的项目，愿意一同与项目成长才能很好的实施DevOps。就像多匹马拉车一样，只有它们都有共同的目标的时候才能快速拉车到目的，如果他们一匹向东一匹西，只会让马车无法前行甚至四分五裂。

　　在我的团队，因为在招聘人员的时候已经进行过了筛选，所以在合作上非常的顺利，当然我也经常在例会和业余的时候都会给大家传达思想，让团队成员真正的从实际意义上去理解现在的做法。

　　对于已经成型的团队来说如何去落地呢？无非三种，激励、考核和逐步试行。如果有条件的公司可以设置奖金激励，如果有绩效考核的可以将DevOps实施纳入考核目标，如果两者都没的，那就选取团队里愿意改变的同事进行试行，使用过后都说好的那么更会有说服力。　

流程　

　　为了落实了文化的改进与技术的使用的这个过程，我们需要科学的、有步骤、有计划的方式完成这项工作，并且可以让这套标准化的方式可以重复使用到其他项目上。

　　在我的团队是有产品、前端开发，后端开发、测试、运维组成的。我采用了原型模式 DevOps模式：

• 　　产品人员会优先使用Axure RP工具把需求整理产出原型并与需求方确认。
• 　　产品确认好的原型就是我们技术的输入，技术拿到需求后会做一次需求评审，主要是排查需求疑惑和确认需求目标。
• 需求明确后，由我使用Visual Project任务拆解与排期，任务会建立在我们的项目管理系统Redmine上，如果任务周期过程，我会拆分成多个可交付的短周期，一般会控制在2个星期内。
• 　　接到任务后，大家就跟根据自己的任务使用PowerDesigner数据库设计（早期是由我独裁设计，后期团队发展壮大了，就由业务负责人各自设计），在这个阶段，如果有新的服务与新的工具库需要部署，我就会正面与运维沟通让他把自动化给完成。
• 　　因为我们是前后端分离的，所以我们使用了Swagger减少了写接口文档的时间，所有任务是否完成以前端是否对接好接口为主导，前端对接好后，就会在Redmine修改自己的任务状态并新建一个测试任务给到测试。
• 　　测试会根据自己写好的测试用例，进行对完成的任务进行场景测试，如果有BUG会在Redmine提给相应的人进行修改。一般会先由前端人员排查是否是他的交互上的BUG，如果确认是数据问题那么就会转给后端开发，开发人员定位BUG时，可以通过我们的SkyWalking和Kibana联合定位问题，定位问题时间一般都在2-10分钟。
• 　　代码合并到测试分支后就会通过Jenkins发布到测试环境，生产环境的发布是合并到生产环境后手动确认发布的。

　　除此之外，每周一会有一个例会内容不限工作，也可以分享周末去哪里娱乐了。在该迭代周期快到结束的2-3天会开一个进度会议，看看大家完成情况。因为公司没有下午茶，所以我们自己通过玩抢红包领到最大的两个的请吃下午茶，最少一星期一次。

结束

　　该篇到这里就分享结束了，也是该系列的最后一篇，我曾经认为技术与管理必须二选一，自从我成为了一个技术与团队的负责人后，终于让我认识到，一个优秀的技术思想还是需要一些管理手段才能很好的实施，而我们的技术管理无非就是软件工程。