网易杭州研究院·尧飘海

本文作于2015年2月

接前文：PaaS服务之路漫谈（二）

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架构的应用，我们的自动部署平台系统能较好的担当这类角色，但是对于MSA服务架构的项目，自动部署平台系统尽管也能部署，但是也会遇到上面提到部署问题，比如：主机数量爆炸式的增长带来的管理成本，对资源的合理使用等。如何解决这些问题，需要大家一起努力来解决，特别是如果和GOOGLE一样每周需要20亿个服务部署的时候，我们对应的服务能跟上业务的需求不？我们的PaaS的服务能否很好的面对这些挑战？作好准备了吗？

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

最后，PaaS可能是一套开发、测试、运维的规范和流程的实战总结，也可能是系统化的工具组合，但业务和技术是不断变化的，没有哪个理论和工具能一劳永逸地回答和解决所有问题，只有最好，只有适合，所以PaaS也不是银弹。

期待大家提供高见建设我们的PaaS服务之路！

「

往期回顾

」

﹀

﹀

﹀

PaaS服务之路漫谈（二）

PaaS服务之路漫谈（一）

网易云信∣真正稳定的IM云服务

ID：neteaseim  长按识别，关注精彩