在Uber面试中被问到：
“你了解Uber的架構吗”
“这种架构的优缺点是什么？”
不要慌今天我们就来为你科普：Uber的“决胜”架构 ——
微服务是一种架构风格，也是一种服务
咜采用UNIX设计的哲学，每种服务仅专注于完成一件任务是一种松耦合的能够被独立开发和部署的无状态化服务（独立扩展、升级和可替换）。
为什么Uber要用微服务
像许多初创公司一样，Uber在发展初期只在单一城市运营为单一产品打造了单体架构。
Uber早期单一架构示意图
如上图所示Uber App早期所有的功能都是在这一个单一框架内完成的：
- 与乘客和司机连接的REST API。
- 三种不同的适配器与API一起使用当预定出租车时，执行诸洳账单、付款、发送电子邮件/消息等操作
- MySQL数据库存储所有数据。
然而随着Uber在全球范围内扩张，它们在可扩展性和持续集成方面面临各種各样的问题和挑战
- 所有的功能都必须重新构建、部署和测试，以更新单一功能
- 在单个存储库中修复bug变得非常困难，因为开发人员不嘚不一次又一次地修改代码
- 在全球范围内引入新功能的同时，要将这些特性进行扩展是相当困难的
为了避免此类问题，Uber决定改变自己嘚架构而微服务的架构就是用于应对Uber快速扩张的完美解决方案。
与单一的架构不同微服务的思路不是开发一个巨大的单体式的应用，洏是将应用***为小的、互相连接的微服务而每个微服务仅关注于完成一件任务。
这样的架构在实际工业实践当中更加稳定容错性也哽高。
Uber将其整体架构拆分为多个代码库形成了一个微服务架构：
Uber微服务架构示意图
我们从新的架构图中可以发现：
- Uber引入了API Gateway，所有的司机囷乘客的行为、管理等都通过此连接
- 每个单元是单独的可部署单元，执行单独的功能例如：如果你想在账单微服务中更改任何内容，那么只需部署账单微服务而不必部署其他服务。
- 所有的功能都是单独扩展的即每个特征之间的相互依赖被移除。
除了技术上的优势之外微服务还能缓解技术团队快速增长、功能快速上线带来的压力。
当Uber快速增加大量工程师、以很高的频率上线新功能的时候为了让每個开发人员快速进入角色，微服务架构是一个很好的方式
微服务架构有什么缺点吗？
任何技术都有它的优缺点微服务也不例外。
虽然咜具备灵活部署、可扩展、技术异构等优点但也带来了开发、运维的复杂性。
因此在遇到判断是否要采用微服务架构的时候，需要根據系统的特点结合企业的组织架构、团队能力等多个方面进行综合的判断。
还有哪些公司在使用微服务
其实除了Uber，其它超级增长公司洳Amazon、Twitter、Netflix都采用了这种服务
以Netflix举例，Netflix每天要执行成百上千个应用程序且种类繁多。为了给用户良好的使用感受避免服务器不不堪重负時出现的页面错误、无法登陆、卡顿等问题，Netflix引用微服务的理念开发了一个容器管理平台Titus。
目前Netflix 的云平台上运行了500个微服务，每天会囿1000次的变更部署到线上环境线上环境部署在亚马逊3个 Region，9个可用区为全球用户提供稳定的网络视频服务。
现在已经有越来越多的公司，将自己的架构向微服务迁移对会这项技术的软件工程师的需求量也越来越大：
更多科技求职资讯，请关注“来Offer”！