大型互联网公司的微服务转型实践1.docx

PAGE 24 大型互联网公司的微服务转型实践 微服务是一个比较大的话题，本文将以 Netflix 为例，分享一个大型互联网公司如何从一个 Monolithic 的 APP 成功转型到微服务。 文章主要涉及微服务的产生历史，应用场景，与单片服务区别，微服务带来的技术、企业组织结构等方面挑战，以及如何合理地选择单片服务构架和微服务构架等内容。 微服务的产生历史 如下图，是微服务在 Google 的搜索结果： 自 2014 年以来，微服务开始被关注，搜索的人越来越多，并在 2016 年左右达到顶峰。从地域来看，很多国家都在关注，如印度，欧洲等等，并且很多公司在使用微服务构架。以下以 Netflix 为例来分享微服务的演变过程以及带来的挑战。 Netflix 的微服务演化 我 2012 年加入Netflix，从中了解到： Netflix 从 2008 到 2009 年就开始在自有数据中心做单片的 Web 应用，那个时期是很庞大的 Java 包，无数的程序写在其中，造成很多问题。 2010 年开始把重量级的部分转出。 2013 到 2014 年，其他的模块也陆续转出，并发布很多 Open?Source 的微服务工具，在硅谷及全球受到很多人的关注。 直至 2015 年左右，Netflix 基本完成向微服务的转型，也彻底从自有数据中心，转移到亚马逊的云平台。 如下，是微服务示意图： 微服务看上去很复杂，其实它是一个个服务器组成的，这些服务器之间相互连接。 如下图，是 Netflix 在微服务方面的使用情况： 从时间点看，Netflix 是硅谷采用微服务比较早的公司，在采用过程中也受到很多质疑，特别是传统公司，从数据中心迁到云上，需要时间来慢慢接受。 微服务、单片服务两者的概念与区别 如下，是很普遍的 Monolithic APP 示意图： 从 Browser 到各种公司的 Apache，形成一个包含各种功能的 WAR 包，最后是一个 MySQL 的存储层。这样的方式，比较易于测试，部署方面也很简单。 Monolithic APP 的优点如下： 易于开发。很多 IDE 和框架都支持，比如 Sprint?MVC、Ruby?Rails、Python Django?等。 易于测试。可以通过简单启动应用程序并使用 Selenium 测试 UI 来实现端到端测试。 易于部署。只需将打包的应用程序复制到服务器。 易于扩展。通过在负载平衡器后运行多个副本，可以轻松地水平扩展。 DevOps?比较简单。一支专门 DevOps?团队负责即可。 Monolithic APP 的缺点如下： 应用程序太大且复杂，很难完全理解并快速正确地进行更改。 应用程序会越变越大，可能会减慢启动时间。 必须在每次更新时重新部署整个应用程序。 如果代码库有新的变化，变化的影响通常不是很清楚，这导致广泛的手动测试。 连续部署很困难。 当不同模块具有冲突的资源需求时，单片应用也可能难以扩展。 可靠性差。任何模块中的错误（例如内存泄漏）都可能会导致整个网站宕机。此外，由于应用程序的所有实例是相同的，该错误将影响整个应用程序的可用性。 采用新技术或框架很困难。由于框架或语言的变化将影响整个应用程序，因此在时间和成本上都是非常昂贵的。 随着代码库，组件和团队规模增长，各种问题相继出现。 主要概括为如下几点： 原代码太大，IDE 打不开了。 单机的内存不够，没法编译和跑代码。 部署一次要花很长时间。 开发速度跟不上产品的需求，一个小小的变化需要整个源代码重新编译。 某一个模块里的一个小错误，可能导致整个网站宕机。 随着组织的成长，功能的增多以及技术栈的瓶颈出现，需要有新的变革。但面对如此庞大的视频网站，有的程序都是用的 Java 包，自有数据中心，当时还没有微服务的概念，但已经有了把内容拆分出来的意识。 什么是微服务？ “微”是指团队、代码行数或 API 端口的数目等指标的大小？都不是，不同人对微服务有不同定义。 个人比较赞同这个描述：Loosely coupled service orientedarchitecture with bounded contexts。 关键是 LOOSELY? COUPLED和BOUNDED TEXT，LOOSELY? COUPLED 意味着每个服务可以独立更新，BOUNDED TEXT 意味着一个服务只要做自己的事情，外界以API等接口。 也就是微服务要实现独立部署，拥有独立技术栈、界定上下文，明确的所有权等特点。 微服务与单片服务的对比 如下，是微服务与单片服务很形象的对比图： 单片服务是把所有的东西放在一个大盒子里，这个大盒子里什么都有。微服务更像是车箱，每个箱子里包含特定的功能模块和物品，所有东西可以很灵活地拆分出来。 也就是说，在 Mon