BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

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

| 作者 郭蕾 关注 8 他的粉丝 发布于 2015年10月22日. 估计阅读时间: 8 分钟 | 如何结合区块链技术,帮助企业降本增效?让我们深度了解几个成功的案例。

微服务已经成为当下最热门的话题之一。它是一种新的架构风格,涉及组织架构、设计、交付、运维等方面的变革,核心目标是为了解决系统的交付周期,并降低维护成本和研发成本。相比传统的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系统真垃圾,又挂了之类…..)。我们努力了几年了,就是想让我们的监控系统能在舆论之前监测到系统的异常状态,但很难,所以现在我们也在重点考虑舆情监控。

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我
社区评论

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

讨论

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT