技术只是基础

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

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

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

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

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

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

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

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

架构核心要素

　　核心的主要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天会开一个进度会议，看看你们完成状况。由于公司没有下午茶，因此咱们本身经过玩抢红包领到最大的两个的请吃下午茶，最少一星期一次。

 结束

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