PaaS服务之路漫谈（三）

时间 2019-12-02

标签 paas 服务之路漫谈栏目云服务繁體版

原文原文链接

此文已由做者尧飘海受权网易云社区发布。
html

欢迎访问网易云社区，了解更多网易技术产品运营经验。web

Monolithic架构在产品访问量很大的状况下，有可能常会致使整个产品迭代或升级过程不能按预期进行，或者上线风险的不肯定性致使上线时经常信心十足。那么MSA（微服务架构）的模式能在很程度上避免Monolithic架构在规模服务应用下的一些缺陷。算法

微服务架构这个词语出现的较早，其实公司的不少产品也是这么开发和运行的，直到ThoughtWorks的专家讨论过微服务后。Fred George，、James Lewis，Martin Fowler经过专门写博文讨论微服务，才使得微服务变成了下一个时髦术语，但实际上大量的论文也没有划分什么才是真正的微服务，但如今每一个公司都想使用一些微服务来完成产品的开发。数据库

MSA（微服务架构）

在平常的工做中，咱们有可能会有机会接触到运行不少早的大型的遗留系统，除了特别强大的牛人以外，通常的开发人员或者新人基本上没法全面的理解系统内部的运行方式，若是又有新的功能要及时上线，那么处理遗留代码的风险就很高了，常常会出如今对业务理解不全面的状况下修改了某处代码而引入其余关键的部分。日前有些业务团队肯定就遇到了这样的问题，基本经过微服务能较好的解决这个难题，可能按最新的框架模型编写一些小的服务组合起来，完成业务流程，等因此的业务都可以覆盖全面时，那么老的系统基本上就能够下线了。架构

微服务其实只是一种新的架构概念，没有什么新的东西，也没有明确的范围定义，只是经过将功能尽量的按需求分解到各个离散的服务中从而达到各服务间的解藕，甚至能够简单的当作一个个很是小的Monolithic架构组合。负载均衡

微服务是一种简单的应用，每一个服务基本上只完成本身角色的任务，没有额外的业务代码，有些甚至一个算法实现均可能当作一个服务来发布，好比以前Pomelo游戏框架的地图的AOI服务，这些服务基本简单到只能完成一个功能，很是的轻量级和容易理解，公司内的新的项目有些目前基本上采用这样服务化的方式来实现的，只是将一些业务代码简单的包装经过通讯层较好的完成服务调用。框架

这种架构的方式的实现方式以下：运维

相对于前文中的Monolithic架构模式中提到的应用软件开发的非功能要求，这些微服务的架构有什么区别呢？分布式

没错，这种MSA架构实现方式与SOA的模式很是类似，有些人会认为基本上同样的，可是微服务仍是有必定的区别的，SOA的架构早期的采用ESB这种企业总线的方式来实现，里面包括了不少业务规则，消息路由，不少是采用重型的中间件来实现的，总体对开发人员不是很透明，查问题的效率也不是很高。微服务更加轻量级，全部的操做可能直接经过消息传递的方式来实现，中间件只是消息的搬运工，不会对消息进行任务处理。微服务

采用这种架构模式的优点是：

轻量级每一个开发者都能容易理解；相关开发工具对小应用也也较好的支持，而无论相关的机器的配置；整个过程不管是编译，部署过程都很轻量级，这将使用开发人员，测试人员和运维人员工做效率更加高效。
易升级每一个服务均可以独立部署，只要输入输出一致，各服务能够更新的完成运维。
易上手因为代码简单，不管是新入职的员工仍是顶替的角色都能较好的如今业务逻辑，每一个组都能独立工做，减小和其余的组的沟通的开销。
容错性，每一个服务独立部署，某一个服务的失败不会影响总体的业务不可访问，能大大提升用户的SLA服务时间，提升用户的体验。
易扩展因为每一个服务都有对应的资源需求，不多会引发资源竞争，好比各个服务能够链接不一样的数据库来完成对数据库的依赖。
易运维经过复制多份的方式来实现模向扩展，负载均衡完成请求路由。
易掉头微服务能较好的随时使用新技术，新的框架带来的红利，而不用受到技术债的影响。

固然，随着系统服务的逐步细化和扩大，每一个服务单独部署，微服务架构的一些问题也暴露出来了：

因为每一个服务的单独部署，按照日前云计算的使用方式，每一个服务都申请一台云主机来部署，将形成大量的工做时间化在沟通和交流上，包括主机的申请，初始化和权限申请等，其次每一个产品要申请大量的云主机来服务，数量将成指数级别增加，历来进一步带来运维管理等相关问题。
资源的使用方式，微服务采用云主机部署的方式也将使用资源的利用不充分，形成不少的资源浪费，包括内存，磁盘等，之前只有运行一个JVM就能跑起来的服务，如今可能须要运行多个JVM才能完成。
关键性业务复杂，对于一些业务要求很高的场景，好比订单支付之类的服务会引入分布式事务的复杂操做，日前咱们公司也开发了TCC的分布式事务来处理这类问题。
分布式系统经过服务调用，至少增长了一层的开销，固然这种开销通常状况下基本能够忽略，服务端调用除了业务的逻辑以外要的开销很是小；除此以外还须要明确了解本身的业务类型，这样才能更好的根据业务类型部署运行不一样类型的主机上。
测试困难开发人员在完成本身代码开发后，因为涉及到各个系统的业务，所以实现的不一样的测试用例要跨不一样的服务来编写，同时因为分布式事务之类的操做，致使测试场景更加复杂，对于服务的测试须要测试人员编译相关的测试接口和集成测试用例来完成，所以对测试人员的要求会更高。
部署复杂运维人员部署不一样的类型的服务须要了解不一样的部署方法，因为服务的部署复杂，对应带来的协调管理成本也会相应的增长，如何高效的实现服务部署的自动化就变得很是的严峻。经过DEVOPS技术来减小和防止因为繁烦的配置致使事故。

经过二种架构方式的对比，采用何种架构方式来完成应用的部署对于技术负责人或架构师来讲也是一个很是有挑战性的难题，通常在项目的初期或业务上线DEADLINE的需求下，会采用前者架构来快速实现，在项目初期通常也不会遇到很是大的访问量的应用的，同时细化，全分布化服务化的架构也会致使开发速度变慢。而若是业务快速发展，项目的技术架构债也会更加剧，须要人员来完成服务化的架构改造来适用业务的发展。所以什么时候采用架构模式需求根据项目的业务需求和实际的能力来决定，当其余的系统不能很好的服务于项目或不能知足项目的生态需求时，这也是负责人或架构师的职责所在。

一样，在项目开发，测试和上线时，不一样的架构模式须要使用不一样的部署工具来实现高效的自动部署，尽可能减小各人员的沟通和管理等成本，专业人员只要把注意力放在自身的业务范围内，为项目的上线实现工做自身的价值。对于Monolithic架构的应用，咱们的自动部署平台系统(http://omad.hz.netease.com) 能较好的担当这类角色，可是对于MSA服务架构的项目，自动部署平台系统尽管也能部署，可是也会遇到上面提到部署问题，好比：主机数量爆炸式的增加带来的管理成本，对资源的合理使用等。如何解决这些问题，须要你们一块儿努力来解决，特别是若是和GOOGLE同样每周须要20亿个服务部署的时候，咱们对应的服务能跟上业务的需求不？咱们的PaaS的服务可否很好的面对这些挑战？做好准备了吗？

后续本文将继续介绍其余公司的服务化解决方案，包括ebay,Amazon，淘宝等国内外，随后也将详细介绍咱们的实现方案和具体作法，敬请期待。

其实，咱们的PaaS服务化之路刚刚开始；其实，咱们的PaaS服务化之路已经开始；

最后，PaaS多是一套开发、测试、运维的规范和流程的实战总结，也多是系统化的工具组合，但业务和技术是不断变化的，没有那个理论和工具能一劳永逸地回答和解决全部问题，只有最好，只有适合，因此PaaS也不是银弹。期待你们提供高见建设咱们的PaaS服务之路！

参考：

PaaS服务之路漫谈（一）

PaaS服务之路漫谈（二）

网易云计算基础服务深度整合了 IaaS 、 PaaS 及容器技术，提供弹性计算、 DevOps 工具链及微服务基础设施等服务，帮助企业解决 IT 、架构及运维等问题，使企业更聚焦于业务，是新一代的云计算平台，点击可免费试用。

相关文章：
【推荐】浅谈代码结构的设计