马丁.福勒的一个观点是：除非管理单体应用的成本已经太复杂了（太大导致很难修改和部署），否则都不要考虑微服务。大部分应用都应该选择单体架构，做好单体应用的模块化而不是拆分成服务。

因此，系统一开始采用单体架构，做好模块化，之后随着系统变得越来越复杂、模块/服务间的边界越来越清晰，再重构为微服务架构是一个合理的架构演化路径。

四个可以考虑上微服务的情况：

多人开发一个模块/项目，提交代码频繁出现大量冲突。
模块间严重耦合，互相依赖，每次变动需要牵扯多个团队，单次上线需求太多，风险大。
主要业务和次要业务耦合，横向扩展流程复杂。
熔断降级全靠if-else。

微服务的三个阶段：

微服务1.0：

仅使用注册发现，基于SpringCloud或者Dubbo进行开发。
微服务2.0：

使用了熔断、限流、降级等服务治理策略，并配备完整服务工具和平台。
微服务3.0：

Service Mesh将服务治理作为通用组件，下沉到平台层实现，应用层仅仅关注业务逻辑，平台层可以根据业务监控自动调度和参数调整，实现AIOps和智能调度。

微服务架构

先决条件

快速的环境提供能力：

依赖于云计算、容器技术，快速交付环境。
基本的监控能力：

包括基础的技术监控和业务监控。
快速的应用部署能力：

需要部署管道提供快速的部署能力。
Devops文化：

需要具有良好的持续交付能力，包括全链路追踪、快速环境提供和部署等，还需要快速的反应能力（对问题、故障的快速响应），开发和运维的协同工作。

此外，根据康威定律和逆康威定律（技术架构倒逼组织架构改进），组织架构也是一个很关键的因素。对应于微服务架构，组织架构需要遵循以下原则：

一个微服务由一个团队维护，团队成员以三人为宜。
单个团队的任务和发展是独立的，不受其他因素影响。
团队是功能齐全、全栈、自治的，扁平、自我管理。

基础设施

微服务的推行需要依赖于很多底层基础设施，包括提供微服务的编译、集成、打包、部署、配置等工作，采用PaaS平台解决微服务从开发到运行的全生命周期管理，同时提供异构环境管理、容器资源隔离与互通、服务伸缩漂移、服务升级与回退、服务熔断与降级、服务注册与发现。

最基本的基础设施

进程间通讯机制：

微服务是独立进程的，需要确定之间的通讯方式。
服务发现+服务路由: 提供服务注册中心，服务提供者和消费者通过服务发现获取服务的信息从而调用服务，实现服务的负载均衡等。
服务容错：

微服务架构中，由于服务非常多，往往是一个服务挂了，整个请求链路的服务都受到影响，因此需要服务容错，在服务调用失败的时候能够处理错误或者快速失败，包括熔断、fallback、重试、流控和服务隔离等。
分布式事务支持：

随着业务拆分为服务，那么有时候不可避免的就是跨服务的事务，即分布式事务的问题。

原则是尽量避免分布式事务，如果无法避免那么可以使用消息系统或者CQRS和Event Sourcing方案来实现最终一致性。

如果需要强一致性，则有两阶段提交、三阶段提交、TCC等分布式事务解决方案。

提升外部服务对接效率和内部开发效率

API网关: 负责外部系统的访问，负责跨横切面的公共层面的工作，包括安全、日志、权限控制、传输加密、请求转发、流量控制等。

典型的网关功能即对外暴露一个域名xx.com，根据第一级目录做反向路由xx.com/user，xx.com/trade。

每一级目录，如user、trade对应一个服务的域名。

此外，API网关也可以有服务编排的功能（不推荐）。
接口框架: 规范服务之间通讯使用的数据格式、解析包、自解释文档，便于服务使用方快速上手等。

提升测试和运维效率

持续集成：

这一部分并非是微服务特定的，对于之前的单体应用，此部分一般来说也是必要的。

主要是指通过自动化手段，持续地对代码进程编译构建、自动化测试，以得到快速有效的质量反馈，从而保证代码的顺利交付。

自动化测试包括代码级别的单元测试、单个系统的集成测试、系统间的接口测试。
自动化部署：

微服务架构，节点数动辄上百上千，自动化部署能够提高部署速度和部署频率，从而保证持续交付。

包括版本管理、资源管理、部署操作、回滚操作等功能。

而对于微服务的部署方式，包括蓝绿部署、滚动部署以及金丝雀部署。
配置中心: 运行时配置管理能够解决动态修改配置并批量生效的问题。

包括配置版本管理、配置项管理、节点管理、配置同步等。
持续交付：

包括持续集成、自动化部署等流程。

目的就是小步迭代，快速交付。

进一步提升运维效率

服务监控: 微服务架构下节点数目众多，需要监控的机器、网络、进程、接口等的数量大大增加，需要一个强大的监控系统，能够提供实时搜集信息进行分析以及实时分析之上的预警。

包括监控服务的请求次数、响应时间分布、最大/最小响应值、错误码分布等
服务跟踪：

跟踪一个请求的完整路径，包括请求发起时间、响应时间、响应码、请求参数、返回结果等信息，也叫做全链路跟踪。

通常的服务监控可以和服务监控做在一起，宏观信息由服务跟踪呈现，微观单个服务/节点的信息由服务监控呈现。

服务跟踪目前的实现理论基本都是Google的Dapper论文。
服务安全：

内网之间的微服务调用原则上讲应该是都可以互相访问写，一般并不需要权限控制，但有时候限于业务要求，会对接口、数据等方面有安全控制的要求。

此部分可以以配置的方式存在于服务注册中心中，和服务绑定，在请求时由做为服务提供者的服务节点进行安全策略控制。

配置则可以存储在配置中心以方便动态修改。

在微服务数量很少的情况下，以上基础设施的优先级自上而下降低。否则，仅仅依赖人工操作，则投入产出比会很低。

还需要提到的是Docker容器技术。虽然这个对于微服务并不是必须的，但是容器技术轻量级、灵活、与应用依存、屏蔽环境差异的特性对于持续交付的实现是至关重要的，即使对于传统的单体应用也能够给其带来交付效率的大幅提升。

架构设计模式

在引入微服务之后，传统的单体应用变为了一个一个服务，之前一个应用直接提供接口给客户端访问的架构不再适用。微服务架构下，针对不同设备的接口做为BFF层（Backend For Frontend），也叫做用户体验适配层，负责聚合、编排微服务的数据转换成前端需要的数据。服务之间的调用则在允许的情况下（允许延迟）尽可能使用异步消息传递方式，如此形成面向用户体验的微服务架构设计模式。如下图所示：

Client -> API Gateway -> BFF（Backend For Frontend） -> Downstream Microservices

后台采用微服务架构，微服务可以采用不同的编程语言和不同的存储机制。
前台采用BFF模式对不同的用户体验（如桌面浏览器，Native App，平板响应式Web）进行适配。
BFF、API Orchestration Layer，Edge Service Layer，Device Wrapper Layer是相同的概念。
BFF不能过多，过多会造成代码逻辑重复冗余。
可以将网关承担的功能，如Geoip、限流、安全认证等跨横切面功能和BFF做在同一层，虽然增加了BFF层的复杂性，但能够得到性能优势。

服务拆分

微服务架构最核心的环节，主要是对服务的横向拆分。服务拆分就是讲一个完整的业务系统解耦为服务，服务需要职责单一，之间没有耦合关系，能够独立开发和维护。

服务拆分不是一蹴而就的，需要在开发过程中不断地理清边界。在完全理清服务之前，尽量推迟对服务的拆分，尤其是对数据库的拆分。

拆分方法如下：

基于业务逻辑拆分
基于可扩展拆分
基于可靠性拆分
基于性能拆分

其中，对于无法修改的遗留系统，采用绞杀者模式：在遗留系统外面增加新的功能做成微服务方式，而不是直接修改原有系统，逐步的实现对老系统替换。

拆分过程需要遵守的规范如下：

先少后多、先粗后细（粒度）
服务纵向拆分最多三层，两次调用：

Controller、组合服务、基础服务
仅仅单向调用，禁止循环调用
串行调用改为并行调用或者异步化
接口应该幂等
接口数据定义严禁内嵌，透传
规范化工程名
先拆分服务，等服务粒度确定后再拆分数据库。

微服务框架

上面讲述了微服务架构的众多基础设施，如果每一个基础设施都需要自己开发的话是非常巨大的开发工作。目前市面上已经有不少开源的微服务框架可以选择。

Spring Boot

Spring Boot是用来简化新Spring应用的初始搭建以及开发过程的。其虽然不是微服务框架，但其设计的初衷本质就是微应用的底层框架，因此非常适合用于微服务基础设施的开发以及微服务的应用开发。尤其对于Spring技术栈的团队来说，基于Spring Boot开发微服务框架和应用是自然而然的一个选择。
Dubbo&&Motan

Dubbo阿里开源的服务治理框架。其出现在微服务理念兴起之前，可以看做是SOA框架的集大成之作。但其仅仅包含了微服务基础设施的部分功能，诸如熔断、服务跟踪、网关等都没有实现。

Motan则是微博开源的类似Dubbo的RPC框架，与Dubbo相比更轻量级。

服务发现：

服务发布、订阅、通知
高可用策略：

失败重试（Failover）、快速失败（Failfast）、资源隔离 - 负载均衡：

最少活跃连接、一致性 Hash、随机请求、轮询等
扩展性：

支持 SPI 扩展（service provider interface）
其他：

调用统计、访问日志等

Spring Cloud

Spring Cloud是基于Spring Boot实现的微服务框架，也可以看做一套微服务实现规范。基本涵盖了微服务基础设施的方方面面，包括配置管理、服务发现、断路器、智能路由、微代理、控制总线、全局锁、决策竞选、分布式会话和集群状态管理等。其基于Spring生态，社区支持非常好。但其很多组件都没有经过生产环境验证，需要慎重选择。

Spring Cloud Netflix是Spring Cloud的一个子项目，是Spring对Netflix OSS的集成实现。基于Netflix的大规模使用，其中的已经被广泛使用的组件包括：

此外，另一个子项目Spring Cloud Alibaba则是Alibaba开源的基于Spring Boot的微服务框架，主要是对阿里云服务的支持。

Eureka：

服务注册和服务发现
Ribbon：

弹性而智能的进程间和服务通讯机制，客户端负载均衡
Hystrix：

熔断器，在运行时提供延迟和容错的隔离

总结

蚂蚁面试比较重视基础，所以Java那些基本功一定要扎实。蚂蚁的工作环境还是挺赞的，因为我面的是稳定性保障部门，还有许多单独的小组，什么三年1班，很有青春的感觉。面试官基本水平都比较高，基本都P7以上，除了基础还问了不少架构设计方面的问题，收获还是挺大的。

资料领取方式：戳这里

经历这次面试我还通过一些渠道发现了需要大厂真实面试主要有：蚂蚁金服、拼多多、阿里云、百度、唯品会、携程、丰巢科技、乐信、软通动力、OPPO、银盛支付、中国平安等初，中级，高级Java面试题集合，附带超详细答案，希望能帮助到大家。

保障部门，还有许多单独的小组，什么三年1班，很有青春的感觉。面试官基本水平都比较高，基本都P7以上，除了基础还问了不少架构设计方面的问题，收获还是挺大的。

资料领取方式：戳这里

为什么大公司一定要使用微服务？微服务杂谈(1)，推荐学习相关推荐

大公司使用Linux系统的使用方式
世界上最大的技术支持.软件和硬件公司每天使用Linux完成各种任务与解决方案,那么这些大公司究竟是怎么使用Linux的呢?其实并不神秘,本文为你揭晓答案,大多数公司都不会使用Linux作为桌面操作系统 ...
信创浪潮下，看看大公司是如何建立数据安全保护体系的？
信创,即信息技术应用创新产业,它是数据安全.网络安全的基础,也是新基建的重要组成部分.信创涉及到的行业包括IT基础设施:CPU芯片.服务器.存储.交换机.路由器.各种云和相关服务内容,基础软件:数据库 ...
在大公司做凤尾，还是在小公司做鸡头？如何选择
大家都知道互联网大公司一向以技术强悍而知名,BAT的技术在国内互联网公司里算是比较领先的了,这也是因为大公司的业务繁杂庞大,必须要有足够优秀的技术去支撑. 相对而言,小公司更倾向于选用快速扁平化的技术 ...
身为iOS开发，你是愿意在大公司做凤尾，还是在小公司做鸡头？
前言: 大家都知道互联网大公司一向以技术强悍而知名,BAT的技术在国内互联网公司里算是比较领先的了,这也是因为大公司的业务繁杂庞大,必须要有足够优秀的技术去支撑. 相对而言,小公司更倾向于选用快速扁平 ...
在大公司做凤尾，还是在小公司做鸡头？
阅读本文大概需要 4 分钟. 作者:黄小斜大家都知道互联网大公司一向以技术强悍而知名,BAT的技术在国内互联网公司里算是比较领先的了,这也是因为大公司的业务繁杂庞大,必须要有足够优秀的技术去支撑. ...
为什么大公司一定要使用微服务？
这几年在 Java 工程师招聘时,会看到很多人的简历都写着使用了 Spring Cloud 做微服务实现,使用 Docker 做自动化部署,并且也会把这些做为自己的亮点. 而比较有趣的这其中以小公司出 ...
微服务杜家豪_搞好“微建设微服务”也是大业绩
<新湘评论>2017年第06期,湖南省委书记杜家毫发表署名文章<做经得起历史和人民检验的发展业绩>.文章认为,这些年来,湖南人民生活发生了翻天覆地的变化,但实现人民向往的美好生 ...
腾讯投资过 600 多家公司不惊奇，京东也有出手 260+ | 大公司投资并购盘点
来源:IT桔子 A 股一片绿,这已经不是满屏绿色的第一天了,2018 年以来,A 股经历了起起落落落落落落--尤其在中美贸易战不断升级后,A 股的代表颜色就成了绿色,少数会有几家企业翻红,然而过不了几 ...
做 NLP 算法研究，去大公司还是创业公司？
答案当然不是大公司.虽说计算资源这一个点,现在语言模型越搞越大,创业公司恐怕很难负担得起训练成本. 但这么想通常都是错的. 有一家 NLP 创业公司不仅解决了这个问题:他们今年初与国内一家大型云服务企 ...

为什么大公司一定要使用微服务？微服务杂谈(1)，推荐学习