微服务与DevOps

ゝ一世哀愁。 2022-06-05 02:35 259阅读 0赞

微服务强调的是业务系统彻底的组件化和服务化，原有的单个业务系统会拆分为多个可以独立开发，设计，运行和运维的 **小应用** 。单体业务系统是指所有的业务逻辑代码都打包在一个WAR包里面部署，特点是系统紧耦合、整体部署、局部修改，整体更新。单体应用存在如下两个问题：一个是横向扩展时需要整体扩展，资源分配最大化，不能按需扩展和分配资源；另一个是如果单体中有一个业务模块出现问题，就会是全局性灾难，因为所有业务跑在同一个实例中，发生异常时不具备故障隔离性，会影响整个业务系统，整个入口都会存在问题。而微服务可以很好地解决上述问题，微服务的基本思想在于考虑围绕着业务领域组件来创建应用，这些小应用本身是可以在独立的进程里面运行，各个组件之间在部署的时候就能够做到进程级别的隔离。微服务的好处是1）局部修改，局部更新。当对一个单体应用进行修改时，可能要先把整个包给停了，然后再去修改，而微服务只需逐步修改和更新即可；2）故障隔离，非全局。单体应用是跑在一起，所以只要一个模块有问题，其他就都会有问题。而微服务的故障隔离性、业务可持续性都非常高；3）资源利用率高。单体应用的资源利用率低，而使用微服务，可以按需分配资源，资源利用率会非常高。

微服务在具有众多优势外也带来了实施上的复杂性，整个系统由单一应用拆分为N个服务，微服务之间存在较强的依赖关系，服务之间如何协作如何处理就变得非常复杂。由于微服务是一个网状分布的，有很多服务需要维护和管理，对它进行部署维护和监控管理的时候就比较复杂。因此使用微服务，第一步是要构建一个一体化的DevOps平台。DevOps（英文Development和Operations的组合）是一组过程、方法与系统的统称，用于促进开发（应用程序/软件工程）、技术运营和质量保障（QA）部门之间的沟通、协作与整合。DevOps包含了持续集成与持续发布，服务依赖关系管理，服务的发现与负载均衡，以及集中化监控管理。DevOps在实施过程中除了微服务生态系统所必不可少的工具和实践外，还有一个观点非常重要： **微服务不仅表现出一种新型的架构模型，同样也表现出一种新型的组织模型。**

传统的软件组织将开发、IT运营和质量保障设为各自分离的部门。 **开发部门** 的驱动力通常是“频繁交付新特性”，而 **运营部门** 则更关注IT服务的可靠性和IT成本投入的效率。两者目标的不匹配，就在开发与运营部门之间造成了鸿沟，从而减慢了IT交付业务价值的速度。DevOps的推行是按业务来组织团队，团队成员包含设计、开发、测试、运维等，这样一方面可以有效减少服务内部修改所产生的内耗；另一方面，团队边界可以变得更为清晰。DevOps实际是一种文化上的变迁， 打破了传统开发与运维之间的壁垒，帮助组织形成从开发、测试到部署、运维这样一个全功能化的高效能团队。