转载

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

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

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

传统架构面临的挑战

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

对微服务的理解

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

服务治理

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