作者
陈涛
微服务架构的优点和痛点
1、微服务架构的诞生背景
回到互联网早期时代，也就是web1.0时代，当时主要是一些门户网站，单体应用是当时的主流应用，研发团队相对较小，这时候的挑战在于技术的复杂度，以及技术人员的匮乏。
到了新世纪互联网时代，出现了较大规模的一些应用，比如社交、电商等，流量和业务的复杂度也大幅增加，出现了几百甚至上千人的研发团队，研发团队扩大之后，协作问题成为困扰。SOA解决方案是互联网的产物，其核心在于分布式、拆分等。但是因为ESB这样一些单点的组件，所以没有得到很好的推广。阿里巴巴在当时推出的HSF、开源的Dubbo等技术，其实是类似于分布式的一个解决方案，当时就已经有了微服务架构的理念。
微服务架构正式名称的诞生是在移动互联网时代，这时的生活已经实现全面互联网化，各种各样的生活类APP涌现，网民以及流量复杂度相对于新世纪互联网时代显著增强。另外，较大规模的研发团队也已成为主流。这时候，大家普遍都对效率有了更高的追求，而不只是原来只有几个巨头需要有这方面的技术。微服务架构以及微服务技术的推出，如SpringCloud、Dubbo等框架的普及，极大地推广了微服务技术。
现在我们已经进入全面的数字化时代，社会全面互联网化，各种各样的单位（包括政企、相对传统的单位）都需要较强的研发能力。流量的挑战、业务复杂度的挑战、研发团队的扩大等，使得大家对效率有了更高的要求。这时候微服务架构得到了进一步的推广和普及。
微服务架构经过这么多年的发展，是经久不衰的一项技术，为什么它能够有这样持续的发展？
2、微服务架构的优点
我们来回顾一下微服务架构和单体架构的区别，以及微服务架构的核心优势。
单体架构核心的问题在于冲突域太大，包括共享代码库。在研发过程中特别容易冲突；边界和模块的规模不清，使得团队效率也会降低。
而在微服务架构下，核心就在于拆分，包括解耦的研发态，解耦的部署态，极大地释放了团队的研发效率。大道至简，这也是微服务架构为什么能够持续发展的一个原因。
3、微服务时代痛点
根据复杂性守恒定律，我们解决了一个问题，问题会以另一种形式出现，我们又需要去解决。可以看到，微服务时代下会引入非常多的一些痛点，核心就是稳定性。因为从原来的一些本地调用改成远程调用以后，可能会发生稳定性的点激增，包括调度放大，即可能因为底层的一些远程调用问题，造成上层的一些不稳定，以及期间需要做的限流降级、调用链等。
在微服务时代定位一个问题的复杂度，也会成指数级的一个增长，这里面可能还需要服务治理。另外如果没有较好的设计和预先的一些设想，可能会出现微服务应用的爆炸，包括研发人员和测试人员之间的协作也都会成问题。
微服务技术经过这么多年的发展，业界其实已经有了一些解决方案。
如上图显示，如果要比较好地玩转微服务技术，除了开发自己的业务系统以外，可能还要配套地搭建多个系统，包括CI/CD、发布系统、研发流程、微服务组件相关的一些工具，以及可观测性相关的实时监控、告警系统、服务治理、调用链等等，还需要运维基础的IaaS资源。在这个时代，为了更好地运维IaaS资源，可能还需要自己维护一个K8s集群。
所以说，在这样的背景下，很多企业会选择搭建一个运维团队，或者中间件团队，或者说由一些后端研发同学兼职。但是试想，有多少企业对自己内部搭建的这套系统是满意的？系统的迭代效率是多少，有没有踩到过一些开源的坑，这些坑现在有没有解决？这些应该是在企业的CTO、架构师心中一个持续的痛点。
Serverless时代下的解决方案
1、Serverless时代
Serverless从年第一次提出，到年推出了Lambda这样一个引爆性的产品后，短暂地达到了一个影响力的顶峰。但是这样一个新生事物，突然到真实的、复杂的生产环境中，其实有许多不适应，包括需要改善的地方，所以后续几年它可能要进入一个低谷。
但是，Serverless的“将简单交给用户，复杂留给平台”的理念，其实是非常正确的一个方向。所以在开源界包括业界，其实都在持续性地进行Serverless方面的一些探索和发展。
阿里云在年推出了函数计算（FunctionCompute，FC），在年推出了Serverless应用引擎SAE，在年以及后续的这些年，阿里云持续地在Serverless领域进行投入，支持了包括镜像部署、预留实力、微服务场景等。
2、Serverless市场概况
在年最新的Forrester评测中，阿里云Serverless产品能力是中国第一、全球领先，阿里云的Serverless用户占比也是中国第一。这侧面说明了阿里云Serverless是已经越来越多地进入到企业真实的生产环境中，越来越多的企业认可Serverless以及阿里云Serverless的能力和价值。
3、SAE解决方案
可以看到，在传统的微服务架构下面，企业要用好微服务相关的技术需要自己研发非常多的解决方案，那么在Serverless时代下，在SAE这个产品里面是怎么解决的？
我们可以看到，SAE将Serverless这个理念发扬到了极致，不仅仅托管了IaaS资源，包括上层的K8s，另外还集成了白屏化的PaaS以及企业级微服务相关的套件和可观测相关的套件。在SAE整体解决方案里面，针对这些都进行了很好的集成，给用户提供了一个开箱即用的微服务解决方案，让企业和开发者能够很简单地使用微服务。
1、0门槛PaaS
图中可以看到，SAE在最上层给用户提供的是一个白屏化的操作系统，它的设计理念非常符合企业一般的PaaS系统，包括发布系统或者一些开源的PaaS系统，这样极大地降低了企业上手SAE的门槛，甚至可以说零门槛，包括它也集成了阿里巴巴最佳的一些发布，即发布三板斧——可观测、可灰度、可回滚。
另外它也提供了一些企业级能力的增强，包括命名空间环境隔离、细粒度的权限控制等等。从图中可以看到，在一个企业里面，如果有两个相互比较独立的模块，完全可以通过命名空间进程进行隔离。
2、微服务治理增强
在微服务治理增强方面，特别是在Java语言，SAE采用了一个agent，对用户来说相当于是无侵入、无感知、零升级，而且agent的全面兼容开源，使用户几乎在无修改的情况下，就可以使用无损下限、API管理、限流降级、链路追踪等等能力。
3、前后端全链路灰度
这里展开两个能力，第一个能力是前后端全链路灰度。SAE借助前面提到的agent技术，从web请求到网关到consumer到provide进行了一个全链路的打通，使用户可以通过很简单的白屏化配置，就可以实现一个灰度发布场景。而这样的技术如果企业需要自建，这里面的复杂度大家应该是非常清楚的。
4、CloudToolkit端云联调
第二个能力就是CloudToolkit的端云联调。大家都知道微服务的场景下面应用数量是呈现一个爆炸的趋势，如果本地需要开发，需要启动那么多的应用，如何能够安全便捷地联调云上的一个服务？现在借助CloudToolkit，用户可以很简单地在本地就打通云上的环境，进行一个端云联调，极大地降低开发测试的门槛。
5、强大的应用监控诊断
在微服务的场景下，因为微服务的急剧发散、调用链路的极度增长，在有问题的场景下面定位问题是非常复杂的。而SAE集成了阿里云各种各样的可观测产品，包括Prometheus、IaaS、SLS、基础监控等，在TracingLoggingMetrics等方面都提供了丰富的解决方案，包括请求链路的查询，常用的诊断场景的指标分析，基础监控、实时日志、事件通知等等，这些都能极大地降低企业在微服务台运行场景下的一些日常定位问题。
SAE的技术原理和极致弹性建设
前面已经针对三部分，也就是零门槛PaaS、企业级微服务套件、可观测进行了一个讲解。那么现在要介绍Serverless的一个核心模块，也就是IaaS层面上免运维以及弹性能力的建设。
1、SAE业务架构
通过这张SAE的业务架构图，大家就可以相对比较清晰地看出，在SAE里面IaaS资源包括存储、网络等是不需要用户关心的。另外SAE也托管了K8s这个PaaS层的一个组件，相当于用户也不需要自己去运维K8s。在K8s层之上，SAE提供了微服务治理、应用生命周期管理等增强的能力。另外在弹性方面，SAE的弹性能力达到了15秒，相信在很多企业级的场景下，这已经能帮助开发者较好地应对一些突发流量的情况。另外通过多套环境以及一些最佳实践，可以达到一个降本增效的效果。
2、SAE技术架构
那么SAE是怎么建设免运维，对用户来说，相当于不需要托管的一个IaaS资源以及K8s资源呢？
上图中可以看到，SAE底层其实是采用了一种安全容器的技术，相比于Docker，安全容器相当于提供了虚拟机级别的一个安全解决方案。在RunC场景下，由于共享内核其实在公有云产品上，a用户有可能穿透到b用户的一个容器内，造成一些安全风险。采用安全容器的技术，也就是虚拟机相关的安全技术，达到了一个生产级别的安全隔离，包括安全容器也进入了K8s以及容器的生态。这样安全容器+容器生态的结合，就实现了较好的安全+效率的一个平衡。
另外在存储和网络的隔离方面，SAE不仅仅需要考虑传统的K8s上的网络隔离，也需要考虑在公有云产品下，大部分用户已经在公有云上有非常多的一些存储资源、网络资源，这些也需要进行一个打通。
SAE采用了云产品的ENI网卡技术，将ENI网卡直通到了安全沙箱内，这样相当于用户不仅仅实现了一个计算层的隔离，也实现了网络层的打通。
可以看到现在主流的安全容器技术有Kata、Firecracker、gVisor等等，在SAE里面是采用了最早也是最成熟的Kata技术来实现一个计算成安全的隔离。另外安全容器不仅实现了一个安全的隔离，也实现了一个性能隔离和故障隔离。
举一个比较好理解的例子，在RunC大家共享内核的场景下，一个用户的Container造成了一些内核的故障，是直接可能影响到物理机的。在SAE使用安全容器基础上就没有这方面的风险，最多只会影响到那一个安全容器。
3、极致弹性极致成本
下图中可以看到，如果弹性效率达到了一个极致，用户的成本也可以达到一个极致。通过左右两边的图的对比，大家可以理解弹性对用户成本可以达到的一个效果。
1、SAE极致弹性建设：部署重启
SAE在弹性方面做了哪些事情呢？可以看到传统的K8s的一个Pod的创建过程需要经过调度、initcontainer的创建、拉取用户镜像、创建用户容器、启动用户容器、应用运行等等阶段，它虽然符合K8s的设计理念和规范，但是在生产环境下，对一些需要相对比较要求效率的场景，其实就不太满足企业级的要求。而SAE借助于阿里巴巴开源里面的CloneSet组件的原地升级策略，相当于不需要重建整个Pod，而只需要重建里面的container省去了调度以及inntcontainr创建的一个过程，部署效率达到了42%的提升。
2、SAE极致弹性建设：弹性扩容
在镜像预热场景SAE也实现了一个并行的调度。可以看到，在标准的场景下，调度到用户拉取镜像是一个串行的过程。那么在此做了一个优化，就是在识别到pod即将调入到单个物理机的时候，它就会并行地开始拉取用户的镜像，这样也可以达到一个弹性效率30%的提升。
3、SAE极致弹性建设：Java启动加速
那么在应用启动这个阶段，我们也做了一些弹性效率能力提升的事情。比如说Java的应用，在Serverless场景下其实一直有启动慢的痛点，核心在于Java需要一个个加载。而在一些企业级的应用里面，针对成千上万的class的加载，这肯定是一个相对较缓慢的过程。
SAE结合阿里巴巴开源的Dragonwell实现了AppCDS的技术，它会在应用第一次启动的时候，将class加载打到一个压缩包中，后续的应用加载，只需要加载压缩包即可，免去了大量class的一个串行化的加载，实现了部署效率45%的一个提升。
4、SAE极致弹性建设
最后在应用运行态，我们也做了一些弹性方面的增强。微服务的应用通常会需要配置非常多的一些线程，这些线程通常和Linux的底层线程是一一对应的。在高并发场景下，这里面就会有较大的线程切换的开销。SAE结合阿里巴巴开源的Dragonwell，WISP线程的技术，将上层的几百个线程对应到了底层的十几个线程，极大的降低了线程切换的一个开销。
上图中是我们一个压测的数据。红线就是使用了Dragonwell、WISP的技术，可以看到运行效率有20%左右的提升。
以上就是SAE在Serverless、IaaS托管以及K8s托管方面，还有在弹性效率方面建设的一些技术原理和效果。
总结和展望
原来的微服务用户需要自建非常多的组件，包括PaaS微服务一些技术框架，运维IaaS、K8s，还包括可观测组件等。SAE针对这些方面都做了整体的解决方案，使用户只需要
转载请注明：http://www.0431gb208.com/sjszlff/1518.html
