微服务和容器时代，研发与运维都面临诸多挑战，微服务在带来良好的设计和架构理念的同时，也带来了运维上的额外复杂性，尤其是在服务部署和服务监控上。那么，运维是如何看待微服务和容器的呢？传统的单体应用又该如何完成微服务拆分？如何进行微服务之间的依赖关系管理？
单体应用 VS 微服务
单体应用存在如下两个问题：一个是横向扩展时需要整体扩展，资源分配最大化，不能按需扩展和分配资源；另一个是如果单体中有一个业务模块出现问题，就会是全局性灾难，因为所有业务跑在同一个实例中，发生异常时不具备故障隔离性，会影响整个业务系统，整个入口都会存在问题。
微服务的好处：
局部修改，局部更新。当运维对一个单体应用进行修改时，可能要先把整个包给停了，然后再去修改，而微服务只需逐步修改和更新即可；
故障隔离，非全局。单体应用是跑在一起，所以只要一个模块有问题，其他就都会有问题。而微服务的故障隔离性、业务可持续性都非常高；
资源利用率高。单体应用的资源利用率低，而使用微服务，可以按需分配资源，资源利用率会非常高。
微服务带来的复杂性：
微服务间较强的依赖关系管理。以前单体应用是跑在一起，无依赖关系管理，如果拆成微服务依赖关系该如何处理，比如说某个微服务更新了会不会对整个系统造成影响。
部署复杂。单体应用是集中式的，就一个单体跑在一起，部署和管理的时候非常简单，而微服务是一个网状分布的，有很多服务需要维护和管理，对它进行部署和维护的时候则比较复杂。
如何更好地利用资源。单体应用在资源分配时是整体分配，扩展时也是整体扩展，数量可控，而在使用微服务的情况下，需要为每一个微服务按需分配资源，那么该为每个微服务分配多少资源，启动多少个实例呢，这也是非常大的问题。
监控管理难。以前我们用Java，就是一个单体应用，监控和管理非常简单，因为它就是一个1，但是使用微服务它就是N个，监控管理变得非常复杂。另外是微服务之间还有一个协作的问题。
基于容器构建微服务架构
使用微服务，第一步是要构建一个一体化的DevOps平台。如果你不使用DevOps做微服务的话，整个环境会变得非常的乱、非常的糟糕。它会给你的整个开发、测试和运维增加很多成本，所以第一步我们是提高DevOps的能力，能够把它的开发、部署和维护进行很完美的结合，才可以说我们真正能够享受到微服务架构的福利。
容器的出现给微服务提供了一个完美的环境，因为我们可以：
基于容器做标准化构建和持续集成、持续交付等。
基于标准工具对部署在微服务里面的容器做服务发现和管理。
透过容器的编排工具对容器进行自动化的伸缩管理、自动化的运维管理。
所以说，容器的出现和微服务的发展是非常相关的，它们共同发展，形成了一个非常好的生态圈。
持续集成与持续发布
持续集成的关键是完全的自动化，读取源代码、编译、连接、测试，整个创建过程自动完成。我们来看一下如何用Docker、Maven、Jenkins完成持续集成。
首先是开发人员把程序代码更新后上传到Git，然后其他的事情都将由Jenkins自动完成。那Jenkins这边发生什么了呢？Git在接收到用户更新的代码后，会把消息和任务传递给Jenkins，然后Jenkins会自动构建一个任务，下载Maven相关的软件包。下载完成后，就开始利用Maven Build新的项目包，然后重建Maven容器，构建新的Image并Push到Docker私有库中。然后删除正在运行的Docker容器，再基于新的镜像重新把Docker容器拉起来，自动完成集成测试。整个过程都是自动的，这样就简化了原本复杂的集成工作，一天可以集成一次，甚至是多次。
服务发现与负载均衡
服务发现与负载均衡使用的是Kubernetes的架构。每一个微服务都有一个IP和PORT，当调用一个微服务时，只需要知道微服务的IP，而不需要关心容器的IP，也不需要关心pod的IP。虽然每个pod也有IP和PORT，但当一个pod启动时，就会把pod的IP和PORT注册到服务发现模块，再进行负载均衡。所以当多个pod启动时，对于用户来说还是只需要知道service的IP，不需要知道后端启动了多少pod、IP是多少，这就解决了网络的问题。
日志集中式管理
以前单体的情况下，单体的数量少，日志数量也相应比较少，而在微服务架构下，因为拆分成了很多微服务，相应的日志会非常多且散，这种情况下需要对日志进行集中的管理。我们可以在每个容器里跑日志监控，把所有日志采集进行集中管理和存储，再通过简易操作的UI界面进行索引和查询。
监控管理
然后就是监控方面了。微服务的量是非常大的，这个时候如何有效地监控是极其重要的。我们刚开始做监控的时候，有几百个实例对同一个关键字进行监控，出故障后会收到几百条短信，因为每一个实例都会发一条短信。这时候严重的致命性的报警就会看不到，因为手机信息已经爆炸了，所以要对报警进行分级，精确告警，最重要的是尽量让故障在发生之前灭亡。因此，在做监控时要对故障提前进行判断，先自动化处理，再看是否需要人为处理，然后通过人为的干预，有效的把故障在发生之前进行灭亡。
但如果所有事情都靠人为去处理，这个量也是非常大的，所以对故障进行自动化隔离和自动化处理也很重要。我们在写自动化故障处理的时候研究了很多常见的故障，写了很多算法去判断，精确到所有的故障，这样基本的常见的故障和可以策划处理的故障都可以自动化处理掉。
结语：
技术发展到了今天，不管是业务规模，还是机器数量都变得异常的庞大，传统依靠人肉运维的方式变得不可取，在微服务和容器时代，运维人员和研发人员需要更加依赖机器去管理机器，这也是以后的发展方向。
更多精彩干货分享
点击下方名片关注
IT那活儿
文章版权归作者所有，未经允许请勿转载,若此文章存在违规行为，您可以联系管理员删除。
转载请注明本文地址：https://www.ucloud.cn/yun/129807.html
摘要：整体情况来说，岁可以从事运维工作，不过还是要考虑综合性发展。 Linux是免费开源的操作系统，也是当下非常受欢迎的技术，而Linux运维作为此技术衍生出来的岗位，广受大家的喜欢，越来越多的人都想要学习Linux技术。那么40岁从事Linux运维合适吗? 现在大部分服务器使用的都是Linux系统，Linux免费、高性能...
摘要：飞贷金融科技副总裁陈定玮大会现场，飞贷金融科技作为金融行业数据库容器化的典型案例，为现场的容器爱好者带来了题为金融领域数据库生产容器化及应用的实践经验分享。 2019年6月20日，由Rancher Labs（以下简称Rancher）主办的第三届企业容器创新大会（Enterprise Container Innovation Conference, 以下简称ECIC）在北京喜来登大酒店盛...
摘要：应用的研发上线运维运营形成闭环，顺利完成从对内服务到公共平台的升级。从功能角度，只能支持静态方式设置反向代理，然后，而平台有服务对应的后端服务和端口是有动态调整需求。架构上是基础组件需要进行升级，数据访问层日志监控系统等。 介绍 MaxLeap早期是一家研发、运营移动应用和手机游戏公司，发展过程中积累了很多通用组件。这些组件很大程度帮公司在移动研发过程中节省了时间和成本，...
摘要：具体技术细节的补充中国人寿两朵云的最底层的容器调度与管理都是使用了平台。决定采纳容器拥抱，对整个中国人寿而言都是一次重大的变革。对中国人寿这样的传统金融企业而言，上一个并不容易。 6月28日，Rancher Labs在北京举办了Container Day 2018容器技术大会。在大会上，Rancher Labs CEO及联合创始人梁胜博士、中国人寿研发中心开发五部副总经理王川、技术处高...
摘要：华为的这种底气正来自于其技术能力的塑造和强健。而华为云正是遗传了华为的这种气质，才能在成立仅一年多的时间里实现飞跃式的发展。华为云不仅继承了华为的气质，还将这种气质不断发扬光大。三十功名尘与土，一朝入云胆气生！从1987年2万元起家，到2017年销售收入突破6000亿元，华为三十年的奋斗与拼搏、积累与沉淀，终于厚积薄发。2017年，华为云正式入场，它要像AWS那样开创一个新的产业。华为云的气...
阅读 1347·2023-01-11 13:20
阅读 1686·2023-01-11 13:20
阅读 1133·2023-01-11 13:20
阅读 1860·2023-01-11 13:20
阅读 4103·2023-01-11 13:20
阅读 2705·2023-01-11 13:20
阅读 1386·2023-01-11 13:20
阅读 3599·2023-01-11 13:20
