微服务集群的高效开发运维策略

白凡

分享：陈锋逸
编辑：白凡

讲师介绍：大家好，我是陈锋逸，今天要跟大家介绍的主题是微服务集群的高效开发运维策略。我是微软的MVP，市场也进行测试方法的联系和运营，我是TDD和BDD，本身也做DevOps方面，运维或开发流程改善都有接触。

今天的主题会介绍关于微服务怎么样进行高效的开发和运维，主要分为几个章节跟大家介绍，第一个跟大家介绍服务架构，为什么需要把它改变成微服务，有什么好处和坏处，我们持续继承，提早发现问题和问题检测的问题，我们通过架构集代码的方法让微服务的部署变得更加容易，当微服务上线之后通过集群监控策略对微服务集群做监控更快速的定位你的问题，然后发现效能不好的地方。

1. 服务架构演进

我们先来看第一个部分，关于微服务部分，到底跟传统的单体架构有什么样的差异，它会带来什么样的问题。大家知道互联网应用层最早都是非常简单的，和老师刚才介绍过详细的部分，最早单体式应用如果有三层式架构在15-20年前是非常了不起的，前端很流行单应用层式，我们的网页全部都写在里面，单页应用层式只有一个。主要的好处是希望你让分工更明确，更抽象化，可以达到低耦合性的架构，层次码才可以重复使用。

过一段时间就有了SOA服务导向架构，让服务和服务之间的依赖性不那么重，比较偏向于微服务的架构，必须通过API、预先定义好的存储远端服务，服务要提供什么接口，提供什么参数它会返回什么资料，这就是类似微服务的雏形，特别在物理隔离做了很多功夫，演进到现在，就是大家常见的微服务架构。

这些架构演进，对一般使用者而言，最大的差异其实对使用者没有感觉，说白了就是把原本非常庞大的架构拆分成按照业务逻辑或者使用逻辑切分成不同层的微服务，按照你的需求让这些微服务做单点容错或机制。

通常单体应用架构叫Monolithic架构，以购物占为例，会以商品、广告、金流、使用者、订单、购物车等，其实要运维它是非常容易的事情，只要做好部署、测试、监控，就完成了所有网站的事情。

如果你希望满满导向微服务架构，让你网站有更高可用性，带来直接的影响是什么？原本只需要做一件事情，可能现在变得是商品的微服务要一次测试微服务，必须让重复的事情再做一次，如果没有做好基础建设自动化运营的话，等于说你可能拆分完微服务的时候，直接得到的事情是你的工作量会变很多倍，甚至比较严重一点是说如果你没有设计良好的话，会让你变成你的网站架构变得碎片化，有些跨微服务的逻辑，如果你对系统架构不了解的话，你会花很多时间熟悉。或者有些东西被漏掉。

因此如果你想要做好微细服务有一个大的重点就是必须做好基础建设，让这些事情自动化做，甚至你有一套基础框架，不同微服务之间是不是有共用的监控系统或者整个运营平台，做好基础建设之后，定义微服务标准，跨服务的时候有没有定义好接口，埋下一些点做跨服务等等，这些东西尽可能的自动化。

它有它的好处，我们做事情的时候更专注于某个单点，把效能、逻辑更细化。还有一个很重要的一点甚至我们必须要做跨服务沟通的时候，必须要定义好界面，让微服务和微服务之间可以通过明确界面沟通，这样问题才可以降到最低。

从前面几张图大家知道现在大家都会主推微服务，要高效开发的话会遇到一些痛点，现在做微服务之后，可能对整个微服务架构的掌控度是不是足够，我现在这个团队只负责开发，但对于整个系统架构，比如我们有一些负载均衡器，需要装哪些基础包，如果掌握不足，就不知道怎么做。

更重要一点是害怕失败，有可能我不知道我修改的这个东西会不会导致整个微服务崩溃或者影响其他服务等等，这些都无法掌控，如果你没有做好自动化的话，你需要自己做测试、部署工作等等，这些都是你在高效开发微服务的时候遇到的问题。

2. 持续集成

我们接下来介绍一下我们通常会通过哪几个层面帮助我们做微服务的高效开发，首先我们来看一下持续集成，现在在高效运维非常重要的一块，至少让建置工作、测试工作、部署工作做到自动化，如果你有做持续集成、流水线，可以确保问题部署到生产环境被发现，重点是不需要人工介入，对于程序员来说只需要切入代码，有任何错误需要第一时间发布通知，你确保你的环境是隔离的，在我们做环境规划的时候你可能会有测试环境、生产环境，还有权限区分的问题，但如果都要通过人工处理这些的话，很麻烦，如果通过流水线处理可以很好确保每个环境做的操作是没有人工的因素，而全部都是自动的，可以让环境更加一致，更重要的一点可以节省很多时间，更重要的是让工程师专注开发，像建置和测试工作交给流水线去做。

测试工作也很重要，我们会需要通过测试描述你的产品功能，去验证你所做的东西是不是跟你所想要的是预期的，因为有些开发事先写完代码之后运行测试，这个时候你会发现先写代码再写测试，结果写出来的耦合性太高，但相对来说如果先写测试的时候，有时候反而可以更好的把目的描述出来，这样写出来的代码更符合低耦合性，甚至是如果你先写测试的话，会帮你找出潜在的问题，比如说你在做业务设计的时候，你没有想到系统边界的问题，如果你写测试用力，你会发现很多使用情景没有被你考虑过的。

还有一个很重要的一点，必须确保代码可用，最大的重点是说之后才有重构的机会，如果写了一个程序，但没有写测试，过了一阵子之后就没有人改它了，改新功能的时候无法测试它了。你会有重构的机会，就像我刚刚说了，有重构才有更多的调动机会，才会让开发更高效因为你不会害怕增加心功能和重构，有重构才会让你更好维护。说到测试这块，更重要一点是说你是怎么进行测试的，像很多互联网公司，他们算是有专业测试团队，有大量的测试人员，但他们没有用实际工具进行测试，他们通常做测试方法是这样子，这是我们的品，大家麻烦点一点，看起来没有错误就可以上线了，很多东西上到生产环节之后就发现了问题。

最实际的一点，我们从程式码行数与测试需求看，我们分层不同的Sprint来看的话，每个迭代可以增加20Sprnt的代码，程式码会变成2倍，短短4个迭代就增加了2倍，测试人员的需求，只不过经过了4个迭代，测试工作量就变成2倍，用最人工的方法进行测试的话，可能需要短短一年，我的测试团队就要成长7倍，可能比公司应收成长还快。

一定要做自动化测试，产品确保稳定，确保没有任何功能被遗漏，都有被测试到。

如果只做测试就可以确保你的代码是高品质了吗？答案其实不是肯定的，为什么这样说？虽然你有写测试，但是你有关注过你测试的有效性或者测试的涵盖率是多少吗？核心的功能有没有被测试覆盖掉？有些看起来每个提交都有写测试，但是某些商业逻辑或者某些算法没有被测试覆盖掉，当系统出现问题，就可能是那部分没有写测试出现了问题。你要关心测试的涵盖率和重复码，我们程序员要关注如果程式码重复的时候是不是要提早发现，抽取到共用代码库里面去，这样才不会在修改的时候变得很困难。安全性因素，你必须确保常见的弱点不会存在你的应用中，重要的一点就是你的技术。是不是有一些部分需要做重构等等。

在你能够分析这些东西之后才能做一些计划性的负债，其实在软件开发还蛮常见的，大家知道在做新产品的时候，时间是远远不够的，有时候在当下你可能必须要做一些取舍，我可能没办法在这个阶段把所有代码精炼完美，甚至在这个阶段连需求都不明确，你可以通过计划性负债可以让你知道目前哪些地方做的不好，你了解自己的负债是多少之后，你心里有一个底你才能做计划性负债，如果你了解自己负债状况的话，至少在你负债的时候你可以设一个停损点，这样确保不断开发新功能的时候，代码是可以改动的，测试可以添加上去的，如果不这样造成的后果是之后想要改也无法改，想增加测试也因为耦合性高无法测试。良好的开发流程、自动化测试、可以做计划性负债，要做程式码分析，优先偿还负债比较大的部分，最常改动的部分要让它更有弹性，这些东西写完，接下来10年都不会变动就算了，如果业务代码变更最频繁的地方，你要优先关注优先解决，不断进行重构，可以让你欠债的状况维持合理的范围，这是对产品开发最有价值的开发方式，你不可能极度追求完美设计，你要通过持续改善方式让你的产品更稳定，要有良好的开发功能和工具做到这一点。

你通过开源工具做到的。自动化部署也很重要，可能有些公司如果还是手动做介入部署的话，最常发生的事情就是手误，打错一个指令或者没有做预先配置或脚本的话，比如说更新错版本，如果说把资料苦自动升级的脚本没有管理好的话，万一跑错脚本就很危险，不同环境都可以自动提取，越减少人力介入的话，系统流程就越不会有状况发生，可以做到Canary Release就是灰度发布，你要之你自动更新的集群是哪些。

在做微服务之前你要确保持续整合流程，确保你的流水线是健康的，这样之后程序员才可以更加专注写代码部分，测试、建置、程序分析都可以通过这个完成。

我们在这部分虽然说流水线可以覆盖掉80-90%的日常工作，我们看这张图，这个图代表你做什么事情跟你发现问题的时间点，你从这个图会发现很有意思的事情，如果我们做的事情是Programming的事情的话，通过持续集成，在持续整合流程方面，我们还是不会全部依赖机器或者自动化做这个事情，如果可以搭配一些Pair Programming多一个人去验证，如果你写错的东西，另外一个Programming可潜入到你的代码库，可以提醒你，避免很多问题发生。

通过人工检验确保，有时候是程序码全写对，但是商业逻辑错的，这种情况下DD是无法帮你分析的，这个时候你需要通过代码审核才能你部署到生产环节的时候，没有任何环节是遗漏的。

如果想到做到高效开发，你的软件开发是非常重要的，有没有通过适当工具辅助，让基本常见的东西通过自动化工具找出你的问题，比如说重复的代码、测试的涵盖率、技术状况，通过持续集成工具找出问题，了解你的技术债，每个软件都有技术债，但是你是不是有计划优先偿还你技术债，也是帮助你高效开发的重点之一。

3. 架构即代码

大家也知道我们通常在做一个很典型的网络服务，不管API或者是网站，你通常有三种角色，应用程序、商业逻辑、数据库、SQL关联式或者非关联式数据库，你可能有快取的服务器。

你希望它是一个可延展的架构，并且这些应用程序架构是不会有状态的，不会有状态的意思就是说你可能不会让所有使用者都一定连到同一台机器做流程，做到自动延展，甚至是我们还会希望整个架构是覆盖到的，如果用云端平台的话，如果有任何机器异常的时候，可以自动复原机制，坏掉的那台机器会被直接换掉，市场更新机器可以确保所有机器都在最新的状态。

如果今天要延展到不同云端平台，甚至做四有云和混合云架构的时候，可不可以连接到另外云端服务商，让你的服务可以快速复制，比如说我在台湾有一个机房，在新加坡有一个机房，你可不可以把你的系统价值复制到不同地方去，在云端平台，这些东西你是否会快速进行，而是说每次都要人工进行配置和修改，这些都会是一个做一个Scalbable非常重要的事情。

通常我们进行私服器的安装要手工安装环节需要的东西，需要的软件、需要的代码包，需要手工配置的防火墙、网络架构等等的东西，当然如果是数据规模小，你要管理大量的微服务、数据库，这些用人工做都可以接受，如果你的服务有大量成长，就变成了一百台一千台的时候，如果你没有管理好大量集群的时候，你的集群数量会大量爆增，这种时候我们会希望通过架构即代码的工具帮助我们管理不管从系统架构的规划甚至是到应用层级的安装可以通过代码执行。

Terraform针对你系统价值配置、网络配置、私服器配置、安全配置，它是系统语言，可以通过代码方式描述你的语言，描述你的系统架构长什么样子，通过Terraform代码方式把你的系统写下来，帮助开发人员了解目前系统架构长什么样子，甚至要做改动修改的时候，你可以直接在代码上做修改，整个团队针对架构层面的修改针对讨论。

在应用层面，安装私服器可以通过Ansible，如果你通过Ansible的机器，是必须容易让人快速理解你在私服器上安装了什么，也容易修改配置。

不管你装机器是用实体机器还是DOCKER都可以通过Ansible做私服器安装和建置，接下来我把我的应用程序和微服务通过DOCKER会让你的操作变得简单，我用它最好的好处是我根据不同的方案直接快速根据每个Branch建不同的环节。

可以随时按照你的需求配置，在生产环节，把应用程序配在应用程序专属层面，在数据可以用其他方法做，现在我们用Terraform最大的好处是用HCL/JSON去做，这些东西是程序员比较熟悉的，让你系统架构具体做呈现，比较容易阅读，甚至资源多平台。

像Ansible主要是做Provision，不管是AWS的可以做，可以搭配一些模式，比如说Role Profile Pattern，甚至配置一些延展集群，我们介绍一下Role Profile Pattern，把一个机器变成Role的角色，里面有Nginx、Roils、Fluentd的模组，每一个模组都可以重复使用，所以可以快速组出新的私服器，甚至你可以用它做一些Docker，可以快速建置环境，确保在不同快法机或者运行机的环境是一致的，可以很好的做环境隔离，在同一台机器上运行的不同容器不会互相影响，对测试、运维可以有很多资源进行有效利用，可以让你的运维比较简单，通过容器观察你的服务，它会比虚拟化更加简单。

我们可能在做新时代的云端应用我们希望尽量保持无状态，随时延展、搬迁、确保稳定、重复使用，通过架构即代码的方式可以很好的把虚拟架构通过代码方式呈现，有了代码之后，团队去了解和改动都更容易。

4. 集群监控策略

微服务在线上的机器数量会变得非常多，通常在监控上我们分成比较具体的几个维度，第一是Infrastructure，然后会有服务器层面的维度，还有应用层面的维度，还有跨服务的维度，进行交易流程的时候要跨过三四个维度进行交易。

如果用云端平台，现在Request在峰值的时候数量是多少，这些都可能是在里面发生的问题，观看每个机群每个集群的在做什么。

像我的CPU、Memory，你可以自己写一些脚本监控微服务的资料，确保这台服务器是健康的还是说它已经有一些异常问题了。

有了这些数据之后，你再搭配Grafara的方式，在我们服务器会有代理服务器，会有Rails，不同语言的服务器会有不同的LOG。

如果日志没有处理，有庞大微服务的时候，你要管理它就变成了很辛苦的事情，因为它都是比较零散，甚至散落在各个服务器上的，你会非常不好浏览，像比较常见的方法，我们要做中心化的日志系统，体要持续分析你的日志，你可以搭配资料视觉化工作，了解你的微服务有大量的异常发生还是正常的。通过它预防一些异常，把我服务状态放在监控系统中就知道监控系统是否正常运作。

ELK架构可以用Fluentd搜索你的日志，到你的服务集群，最后通过kibana数据呈现。把这些东西之后到了Kibana的时候，没有经过任何处理的话，它算做了中心的迟滞，但没有那么容易做浏览和监控。

你还需要做日志的处理，比如正规化、过滤、聚合、视觉化，通过这些简单的步骤之后，你可以把它变成应用层日志的仪表板，日志程序的状态你就可以通过仪表板看到。

最后一个部分在微服务中特别重要的跨服务状态怎么监测，服务流程是否正常，当我进行交易的时候，它可能会进行三四个微服务，交易流程是否正常，有预防性的当拆分成微服务后，在彼此沟通之间是否有效能瓶颈，这些东西可以通过Open Tracing实现，让你微服务之间的通讯通过图表方式进行具像化，每个请求都有UUID，追踪每个服务花的时间是多少。

你就比较容易监控你的服务是否有断点，你再搭配一些，类似这种图片，我可以知道每个API在每个服务花的时间多少，目前的流程是否有断点，我们把不同仪表板结合起来，就成了体快速定位的很好的工具。

最后是做咨询整合，看看关键咨询有哪些、服务的健康状况，要及时更新到仪表板上可以快速监控，可以看特定时间问题，找状态是否正常，可以做额外的记录，如果你要做长久追踪的话，要做长久改善。最重要的一点，如果我们有了这么完整的监控系统，比如我有特别的峰值，公司有大型活动的时候，我可以通过预先设定好的排程，我要做大活动的分析，我就有完整的参考依据，可以做日后的效能改善或重构的规划，我可以找出目前的瓶颈点在哪里，就有优化的数据来源。

怎么做咨询收集和分析业用以及你怎么关注重点在哪里，主要就是说监控系统重要，因为有了这些东西之后，不管你的服务多落后，你就可以很好的掌握它，掌握之后就不怕改动它。

5. 总结

最后作一个总结，其实在前面提了微服务的痛点，通过架构即代码让你对系统架构、服务器设置、应用程序、框架的掌握度变得更高，让流程自动化，甚至你做到这些，你可以单键回滚，搭配持续集成，把整个流程串联在一起，主要重点是我们希望持续交付高品质产品，并且保持它稳定，你做高效运维开发的时候，这些工具所希望帮你达成的目的。

从我们版本控制到体的产品，为了这些事情更顺畅，节省程序员的时间，剩下的事情我们做的这些希望帮助我们做高效开发，让你的事情通过自动化、系统化的方法做运维，让你的程序更稳固，这样让你的开发流程更顺畅，你可以更专注商业流程上，不需要考虑太多的系统问题，我今天的分享到这里，谢谢大家。