本人花费半年的时间总结的《Java面试指南》已拿腾讯等大厂offer，已开源在github ，欢迎star！
www.rowkey.me/blog/2019/05/30/msa/
这几年在Java工程师招聘时，会看到很多人的简历都写着使用了Spring Cloud做微服务实现，使用Docker做自动化部署，并且也会把这些做为自己的亮点。而比较有趣的这其中以小公司出来的人为绝大多数，大的公司出来的人简历上倒是很少提这些东西。
对于我自己来说，从15年就开始关注这一块，看过马丁.福勒最开始的关于微服务的论文、也看过不少对微服务的论证的英文文章和书，也研究过Spring Cloud、Sofa等开源实现以及Service mesh。考虑到我们公司研发团队人力不足、基础设施不完善，当初是没有推行微服务的。但随着看到上述的那种简历越来越多，有时候我也会疑问：难道真的不用微服务就落后了吗？公司的同事如果不掌握这些就真的没有竞争力了吗。而随着最近公司业务的逐步提升，研发人员越来越多，借着在梳理公司的微服务落地计划时，也梳理了一下微服务的相关知识点，也是本文的主要内容。
开篇之前先声明我对微服务的几点态度:
★
-
架构模式有很多，微服务不是唯一的选择也不是什么银弹。国内绝大多数中小公司引入微服务都是在盲目追新，也能看出做此种技术选型的工程师基础架构素质的不足。 -
“你必须长的足够高才能使用微服务”。微服务基础设施，尤其是容器技术、自动化部署、自动化测试这些不完备，微服务形同虚设，不会带来什么质的提升。 -
微服务架构的关键不在于具体的实现，而在于如何合理地划分服务边界以及组织架构是否相匹配。不考虑研发团队的规模和组成就盲目上微服务是不良的技术选型。 -
Spring Boot是Spring全家桶的上层封装，并不是什么崭新的技术，也不是什么值得觉得成为自己杀手锏的技术。 -
Spring Cloud中Spring Cloud Netflix的组件是经过生产环境验证的，其他的则建议慎重选择。
微服务是什么
微服务起源于2005年Peter Rodgers博士在云端运算博览会提出的微Web服务(Micro-Web-Service)，根本思想类似于Unix的管道设计理念。2014年，由Martin Fowler 与 James Lewis共同提出了微服务的概念，定义了微服务架构风格是一种通过一套小型服务来开发单个应用的方法，每个服务运行在自己的进程中，并通过轻量级的机制进行通讯（HTTP API）。关键的三点是small、automated以及lightweight。
对比SOA，微服务可以看做是SOA的子集，是轻量级的SOA，粒度更细的服务，独立进程、数据分离，更注重敏捷、持续交付、DevOps以及去中心化实践。其共同的架构原理：
特点：
综合来看，其优缺点如下：
优点：
缺点：
为什么要采用微服务
是否选择微服务取决于你要设计的系统的复杂度。微服务是用来把控复杂系统的，但是随之而来的就是引入了微服务本身的复杂度。需要解决包括自动化部署、监控、容错处理、最终一致性等其他分布式系统面临的问题。即使已经有一些普遍使用的解决方案，但是仍然是有不小的成本的。
生产力和复杂度的关系如图所示，可见系统越复杂，微服务带来的收益越大。此外，无论是单体应用还是微服务，团队的技能都需要能够把控住。
马丁.福勒的一个观点是：除非管理单体应用的成本已经太复杂了（太大导致很难修改和部署），否则都不要考虑微服务。大部分应用都应该选择单体架构，做好单体应用的模块化而不是拆分成服务。
因此，系统一开始采用单体架构，做好模块化，之后随着系统变得越来越复杂、模块/服务间的边界越来越清晰，再重构为微服务架构是一个合理的架构演化路径。
四个可以考虑上微服务的情况：
微服务的三个阶段：
微服务架构
先决条件
此外，根据康威定律和逆康威定律（技术架构倒逼组织架构改进），组织架构也是一个很关键的因素。对应于微服务架构，组织架构需要遵循以下原则：
基础设施
微服务的推行需要依赖于很多底层基础设施，包括提供微服务的编译、集成、打包、部署、配置等工作，采用PaaS平台解决微服务从开发到运行的全生命周期管理，同时提供异构环境管理、容器资源隔离与互通、服务伸缩漂移、服务升级与回退、服务熔断与降级、服务注册与发现。
提升外部服务对接效率和内部开发效率
提升测试和运维效率
进一步提升运维效率
在微服务数量很少的情况下，以上基础设施的优先级自上而下降低。否则，仅仅依赖人工操作，则投入产出比会很低。
还需要提到的是Docker容器技术。虽然这个对于微服务并不是必须的，但是容器技术轻量级、灵活、与应用依存、屏蔽环境差异的特性对于持续交付的实现是至关重要的，即使对于传统的单体应用也能够给其带来交付效率的大幅提升。
架构设计模式
在引入微服务之后，传统的单体应用变为了一个一个服务，之前一个应用直接提供接口给客户端访问的架构不再适用。微服务架构下，针对不同设备的接口做为BFF层（Backend For Frontend），也叫做用户体验适配层，负责聚合、编排微服务的数据转换成前端需要的数据。服务之间的调用则在允许的情况下（允许延迟）尽可能使用异步消息传递方式，如此形成面向用户体验的微服务架构设计模式。如下图所示：
Client - API Gateway - BFF（Backend For Frontend） - Downstream Microservices
服务拆分
微服务架构最核心的环节，主要是对服务的横向拆分。服务拆分就是讲一个完整的业务系统解耦为服务，服务需要职责单一，之间没有耦合关系，能够独立开发和维护。
服务拆分不是一蹴而就的，需要在开发过程中不断地理清边界。在完全理清服务之前，尽量推迟对服务的拆分，尤其是对数据库的拆分。
拆分方法如下：
其中，对于无法修改的遗留系统，采用绞杀者模式：在遗留系统外面增加新的功能做成微服务方式，而不是直接修改原有系统，逐步的实现对老系统替换。
拆分过程需要遵守的规范如下：
微服务框架
上面讲述了微服务架构的众多基础设施，如果每一个基础设施都需要自己开发的话是非常巨大的开发工作。目前市面上已经有不少开源的微服务框架可以选择。
Spring Cloud
Spring Cloud是基于Spring Boot实现的微服务框架，也可以看做一套微服务实现规范。基本涵盖了微服务基础设施的方方面面，包括配置管理、服务发现、断路器、智能路由、微代理、控制总线、全局锁、决策竞选、分布式会话和集群状态管理等。其基于Spring生态，社区支持非常好。但其很多组件都没有经过生产环境验证，需要慎重选择。
Spring Cloud Netflix是Spring Cloud的一个子项目，是Spring对Netflix OSS的集成实现。基于Netflix的大规模使用，其中的已经被广泛使用的组件包括：
此外，另一个子项目Spring Cloud Alibaba则是Alibaba开源的基于Spring Boot的微服务框架，主要是对阿里云服务的支持。
Service Mesh
上述的微服务框架都是侵入式的，服务化的过程都需要进行代码改造。Service Mesh则是下一代微服务架构，最明显的特征就是无入侵。采用sidecar模式来解决系统架构微服务化后的服务间通信和治理问题。
如上图所示，目前主流的开源实现包括：
- Sofastack
蚂蚁金服开源的构建金融级分布式架构的一套中间件。包 括微服务开发框架、RPC框架、服务注册中心、全链路追 踪、服务监控、Service Mesh等一整套分布式应用开发 工具。
特别值得一提的是SOFAMesh。其是对下一代微服务架 构Service Mesh的大规模落地方案实践，基于 Istio改 进和扩展而来，应该是国内最为成熟的开源Service Mesh方案。
此外，需要提到**Kubernetes(K8s)**，其本身提供了部分的微服务特性支持（通过域名做服务发现），对代码无侵入。但服务调用、熔断这些都需要自己实现。
综上，目前公司技术团队技术栈是Spring，并且已有服务的实现都是基于Dubbo，因此选择Spring Cloud Netflix做为基础的微服务框架，对其中不成熟或者缺乏的组件，选择业界更为成熟的组件替代即可。
参考资料
END
Java面试题专栏
欢迎长按下图关注公众号后端技术精选
原文始发于微信公众号（后端技术精选）：
