终于有人把微服务讲明白了

hzbooks

于 2021-10-25 08:00:00 发布

阅读量273

点赞数

文章标签：大数据人工智能 java 数据库编程语言

原文链接：https://mp.weixin.qq.com/s?__biz=Mzg5MDU5NTM1NQ==&mid=2247526704&idx=1&sn=ae1573ac5e2dcda2662d2b94472dda64&chksm=cfd81844f8af9152f15fb084962b7456509db5797a9f84d50634a4a304a3ad92a849fad54931&scene=126&&sessionid=0

版权

作者：魏新宇郭跃军

来源：大数据DT（ID：hzdashuju）

01 微服务架构简介

微服务这个概念并不是近年才有的，但这两年随着以容器为核心的新一代应用承载平台的崛起，微服务焕发了新的生命力。

传统的巨大单体（Monolithic）应用程序在部署和运行时，需要单台服务器具有大量内存和其他资源。巨大的单体应用必须通过在多个服务器上复制整个应用程序来实现横向扩展，因此其扩展能力极差；此外，这些应用程序往往更复杂，各个功能组件紧耦合，使得维护和更新更加困难。

在这种情况下，想单独升级应用的一个功能组件，就会有“牵一发而动全身”的困扰。

在微服务架构中，传统的巨大单体应用被拆分为小型模块化的服务，每项服务都围绕特定的业务领域构建，不同微服务可以用不同的编程语言编写，甚至可以使用完全不同的工具进行管理和部署。

与单体应用程序相比，微服务组织更好、更小、更松耦合，并且是独立开发、测试和部署的。由于微服务可以独立发布，因此修复错误或添加新功能所需的时间要短得多，并且可以更有效地将更改部署到生产中。此外，由于微服务很小且无状态，因此更容易扩展。

总体而言，微服务通常具有以下特点：

以单个业务或域为模型。
每个微服务实现自己的业务逻辑，包含独立的持久数据存储。
每个微服务有一个单独发布的API。
每个微服务能够独立运行。
每个微服务独立于其他服务且松耦合。
每个微服务可以独立地升级、回滚、扩容、缩容。

02 微服务架构的主要类型

目前在微服务架构领域有多种微服务治理框架，如Spring Cloud、Istio等。这几种微服务架构都符合上一节介绍的微服务架构的特点，但实现的方式不同：有的通过代码侵入的方式实现，有的通过使用代理的方式实现。

在Kubernetes出现和普及之前，实现微服务架构需要通过像Spring Cloud这种代码侵入的方式实现，也就是说，在应用的源代码中引用微服务架构的治理组件。

在Kubernetes出现以后，我们可以将容器化应用之间的路由、安全等工作交由Kubernetes实现，也就是说，应用开发人员再也不必在开发阶段考虑微服务之间的调用关系，只需关注应用代码的功能实现即可。这种无代码侵入的微服务架构（如Istio）越来越受到业内和客户青睐。

03 企业实施微服务架构的收益和原则

从技术角度而言，企业实施微服务大致有以下几个方面收益：

应用更快部署：微服务比传统的单体应用小得多。较小的服务可以缩短修复错误所需的时间。微服务是独立发布的，这意味着可以快速添加、测试和发布新功能。
应用快速开发：微服务由小团队开发和维护，每个小团队最大规模为10人，合理的团队规模是5～7名成员，也就是“双比萨团队”（亚马逊在2012年提出这个概念，意思是5～7人吃两个比萨刚好吃饱）。
降低应用代码复杂度：由于微服务比巨大的单体应用小得多，因此，这意味着每个微服务的代码量是可控的，这让代码修改变得很容易。
应用易于扩展：微服务通常是独立部署的。各个服务可以根据服务接收的负载量灵活地扩容和缩容。系统可以将更多的计算、存储、网络资源分配给接收高流量的服务，实现资源上的按需分配。

虽然微服务优势明显，但为了保证微服务在企业内顺利实施，通常会遵循一些原则和最佳实践：

IT团队重组为DevOps团队：由微服务团队负责从开发到运营的整个生命周期管理。DevOps团队可以按照自己的节奏管理组员和产品，控制自己的节奏。
将服务打包为容器：通过将应用打包成容器，可以形成标准交付物，大幅提升效率。
使用弹性基础架构：将微服务部署到PaaS上而非传统的虚拟机，例如OpenShift集群。
持续集成和交付流水线：通过流水线打通从开发到运维的整个流程，这有助于微服务的落地。

在了解了微服务对于企业数字化转型的意义后，接下来看一看PaaS、DevOps和微服务之间的关系。

04 PaaS、DevOps与微服务的关系

PaaS、DevOps、微服务的概念很早就出现了。广义上的微服务和DevOps的建设包含人、流程、工具等多方面内容。IT厂商提供的微服务和DevOps主要是指工具层面的落地和流程咨询。

在Kubernetes和容器普及之前，我们通过虚拟机也可以实现微服务和DevOps（CI/CD），只是速度相对较慢，因此普及性不高（想象一下通过x86虚拟化来实现中间件集群弹性伸缩的效率）。而正是容器的出现，为PaaS和DevOps工具层面的落地提供了非常好的承载平台，使得这两年容器云平台风生水起。

这就好比4G（2014年出现）和微信（2011年出现）之间的关系。在3G时代，流量费较贵，大家对于微信语音和视频聊天不会太感兴趣；到了4G时代，网速提高而且收费大幅下降，像微信这样的社交和互联网支付工具才能兴起和流行。

容器引擎使容器具备了较好的可操作性和可移植性，Kubernetes使容器具备企业级使用的条件。而IT界优秀的企业级容器云平台——OpenShift又成为DevOps和微服务落地的新一代平台。

OpenShift以容器技术和Kubernetes为基础，在此之上扩展提供了软件定义网络、软件定义存储、权限管理、企业级镜像仓库、统一入口路由、持续集成流程（S2I/Jenkins）、统一管理控制台、监控日志等功能，形成覆盖整个软件生命周期的解决方案。

所以说，OpenShift本身提供开箱即用的PaaS功能，还可以帮助客户快速实现微服务和DevOps，并且提供对应的企业级服务支持。

关于作者：魏新宇，红帽副首席解决方案架构师。在IaaS、PaaS方面有丰富的经验，致力于开源解决方案在企业中的推广和应用。从售前角度主导了红帽在金融、汽车行业的多个PaaS项目。曾就职于华为、IBM、VMware。

郭跃军，目前就职于VMware，担任Solutions Engineer。曾于红帽担任PaaS咨询顾问、AWS顾问服务团队担任云架构咨询顾问，熟悉私有云和公有云生态。从2015年接触容器技术开始，一直奋战在PaaS建设一线，参与了很多OpenShift项目的竞标、PoC、咨询和落地实施，帮助很多企业实现了数字化转型。

本文摘编自《OpenShift在企业中的实践：PaaS DevOps 微服务》（第2版），经出版方授权发布。