先把平台做扎实,再来微服务吧

微服务已经成为当下最热门的话题之一。它是一种新的架构风格,涉及组织架构、设计、交付、运维等方面的变革,核心目标是为了解决系统的交付周期,并 降低维护成本和研发成本。相比传统的SOA架构或者单块架构,微服务有很多的优势,比如技术的多样性、模块化、独立部署等,但也带来了相应的成本,比如运 维成本、服务管理成本等。

网上有很多讨论微服务优缺点的文章,而在这个新的东西面前,很多企业不知道如何抉择。那传统的架构有什么挑战?微服务可以为企业带来什么?切换到微服务架构之前,需要做出哪些准备?10月16日,在QCon上海全球软件架构师大会上,InfoQ组织了一场闭门会议,深入讨论和交流了微服务相关的问题。阿里巴巴、大众点评、唯品会、华为、普元、中国移动、点融等公司的代表参与了此次讨论,本文根据会议中的精彩观点整理而成。

传统架构面临的挑战

  1. 稳定性。很多公司都是从零开始构建自己的系统的,一开始,为了尽快的实现业务,所以系统的架构也相对比较简单。但当业务和用户量开始大规模增长之 后,反过来又对系统的性能和稳定性有较高的要求。而传统的单体式(本文均指monolithic)应用把所有的服务都堆到一起,可能会由于一些不重要的服 务出问题而影响系统的核心服务。另外,系统对服务的要求也不一样,分开部署可以减小它们之间的相互影响。
  2. 可维护性。移动的系统是从2001年开始做的,到现在已经十多年了,这么多年,核心的系统一直是在完善、堆叠。而经过这么多年的维护,系统代码的 可维护性非常差,开发人员和技术都已经迭代过几波,系统中代码之间的调用也很多,不是很了解系统的人也不敢轻易动。而由于系统的代码非常多,所以了解系统 也不是一件容易的事情。
  3. API的版本迭代。单体应用中,一个系统会对应出很多的API,而根据业务的不断迭代,肯定会衍生出很多版本的API,特别是现在很多系统都有不 同的端(手机、网站)。API的升级和维护都需要有相应版本的管理,而单体式的应用在这一块,有明显的短板。另外,API的发布周期也会很慢,因为版本的 发布涉及到整体的协调和测试。
  4. 持续集成。单体式的应用由于比较大,应用内部的依赖非常多,涉及的业务逻辑也比较复杂。在CI流程中,如果没有很好的约定的话,失败的次数也会比较多。另外,由于代码基比较大,所以构建的时间也会非常长,如果构建错误,排查问题也会比较困难。

对微服务的理解

  1. 微服务的概念里,有两个重点,快速发布和解耦。这两点都可以和OO中的架构设计原则相对应,一个是单一职责(single responsibility),也就是把一件事情做好,一个是关注分离(Separation of concerns)。康威定律说:设计系统的组织,最终产生的设计等同于组织之内、之间的沟通结构。对应到这里,也就是说微服务和公司的组织架构有非常紧 密的关系。另外,很多公司都已经是微服务了,只是他们没有提,比如亚马逊、阿里巴巴。像他们这么大的公司,没有微服务根本玩不转。
  2. 微服务革新了软件的生产过程,包括开发、测试和部署各个阶段。但服务的切分并不是要遵守单一原则,因为未来的服务不可能完全垂直切分。从另外一个 角度看,微服务的过程其实也是工业化的工程,每个微服务都是生产线上的一个零件,但要注意,零件的组装和拼接难度更大,所以在谈论微服务时一定要注意,它 是需要一个大平台支撑的。
  3. 首先微服务并不是指代码本身,它包括从代码开发到部署到运维这一系列的工作流程。其次,谈到服务拆分,需要注意的是服务的 SLA(Service-Level Agreement)是不一样的,拆分时需要考虑到哪些是一级服务,哪些是二级服务。最底层的服务直接决定了上层服务的稳定性。
  4. 服务化说白了是组件化的一种形式,所有的组件都来源于重构。流程是从上往下写的,写到一定程度时,就会遇到分离、解耦的问题,然后就是组件化,这时才会出现重构。不要上来就追时髦,服务化没有价值。
  5. 如康威定律所说,系统架构和团队的组织架构有直接的关系。但并不是说为了微服务而调整组织架构,一般是考虑到业务的需求才调整团队组织架构。微服 务的团队推荐是7个人左右,这也是Netflix的最佳实践。另外,团队与团队之间不要有太多依赖。中小型的创业公司不推荐使用微服务,因为开销成本很 高,对平台的要求也很高。微服务涉及到你是否能有快速提供环境的能力、文化的改变、快速部署、监控等多方面的能力,当这些条件都具备之后,再考虑是否要微 服务。

服务治理

  1. 服务治理这块,根据经验,有三个需要注意的。一是接口的统一性,当公司发展到几百人的时候,如果没有接口规范,那效率马上就会下降。之前可以像游 击队一样打,但人多了之后,还是像正规军一样战斗力会比较强。二是容错一定要做好,这块可以参考Netflix开源的几个组件。容错如果没有做好,在服务 化这样的系统里,很可能会造成雪崩效应。容错的方案也有很多,比如限流、回退、隔离、熔断。三是监控,在微服务出错之后,团队需要快速定位出错的位置和原 因。
  2. 服务治理这块,阿里巴巴有个不错的框架Dubbo, 已经开源。抛开服务治理不说,我来举个服务化的反例,Facebook内部是反服务化的。Facebook所有的代码只有两个库,并且所有的发布都是同时 进行的,每个机器都一模一样。所以Facebook可以做到零运维,并且服务根本没有版本的概念。阿里巴巴现在的服务也准备往回收,在没有服务和过多的服 务之间找到一个平衡点。
  3. 服务方需要知道服务会被多少人调用,被哪些业务调用,每个时间点上的状态是怎么样的。一个经验是为每个服务都起一个名字,当出现问题时,可以快速定位到。另外,阿里的eagleye和点评的CAT监控系统,支持对服务调用链和依赖关系进行可视化监控,可以参考学习。
  4. 微服务中,服务的测试是一个非常大的挑战。服务和服务之间会存在依赖,所以环境的搭建可能就会涉及到多个团队,这个时候就需要能快速部署环境,当然现在比较推荐的方案是容器。
  5. 微服务,其实对应的应该是微业务,是为了适应业务的多变/面向最终用户的个性化需求。而微服务的力度,很大程度上是取决于完成一项业务所要设计的 数据存储所在的区域。微服务的监控,和原来的服务监控力度应该是类似的,包括业务、应用、系统多个层次,日志、Metrics、调用链、告警等多个维度。
  6. 提到监控,大家一般都是从系统、应用等层面去考虑。我这里抛一个思路给大家:舆情监控。很多时候,当系统出问题的时候,我们并不是在监控那里得到 消息,而是从微博、微信等渠道中收到用户反馈(XX系统真垃圾,又挂了之类…..)。我们努力了几年了,就是想让我们的监控系统能在舆论之前监测到系统的 异常状态,但很难,所以现在我们也在重点考虑舆情监控。
This entry was posted in 未分类. Bookmark the permalink.

发表评论

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / 更改 )

Twitter picture

You are commenting using your Twitter account. Log Out / 更改 )

Facebook photo

You are commenting using your Facebook account. Log Out / 更改 )

Google+ photo

You are commenting using your Google+ account. Log Out / 更改 )

Connecting to %s