微服务架构

一、是什么

微服务是一种架构风格，一个大型复杂软件应用由一个或多个微服务组成，这些服务使用不同的编程语言实现，以及不同数据存储技术，并保持最低限度的集中式管理。系统中的各个微服务可被独立部署，各个微服务之间是松耦合的。每个微服务仅关注于完成一件任务并很好地完成该任务。在所有情况下，每个任务代表着一个小的业务能力。微服务架构的目的是将大型的、复杂的、长期运行的应用程序构建为一组相互配合的服务，每个服务都可以很容易做局部修改。微服务架构带来可独立部署、高扩展与伸缩、自由选择开发语言、高效利用资源、故障隔离等优点，同时也因为服务多带来分布式事务、服务之间通信、监控、部署等新的问题。

一般来说，微服务架构有如下特征：分布式服务组成的系统；按照业务而不是技术来划分组织；做有生命的产品而不是项目；Smart endpoints and dumb pipes强服务个体和弱通信；自动化运维（DevOps）；容错；快速演化迭代。

微服务架构强调的第一个重点就是业务系统需要彻底的组件化和服务化，原有的单个业务系统会拆分为多个可以独立开发，设计，运行和运维的小应用。这些小应用之间通过服务完成交互和集成。每个小应用从前端web ui，到控制层，逻辑层，数据库访问，数据库都完全是独立的一套。在这里我们不用组件而用小应用这个词更加合适，每个小应用除了完成自身本身的业务功能外，重点就是还需要消费外部其它应用暴露的服务，同时自身也将自身的能力朝外部发布为服务。

 

二、有什么用

如果要谈微服务架构的优势，就得先了解软件系统架构的演变历程。

尧舜禹时期，单一应用架构。只需一个应用，将所有功能都部署在一起，以减少部署节点和成本。 数据访问框架(ORM) 是关键。

封建时期，垂直应用架构，应用拆成互不相干的几个应用，以提升效率。 用于加速前端页面开发的 Web框架(MVC) 是关键。  

解放战争时期，分布式服务架构，垂直应用越来越多，应用之间交互不可避免，将核心业务抽取出来，作为独立的服务，逐渐形成稳定的服务中心，使前端应用能更快速的响应多变的市场需求。 用于提高业务复用及整合的 分布式服务框架(RPC) 是关键。 

改革开放时期，流动计算架构，当服务越来越多，容量的评估，小服务资源的浪费等问题逐渐显现，此时需增加一个调度中心基于访问压力实时管理集群容量，提高集群利用率。用于提高机器利用率的 资源调度和治理中心(SOA) 是关键。

随着互联网的发展，复杂的平台、业务的出现，导致SOA架构向更细粒度、更通用化程度发展，就成了所谓的微服务。微服务是SOA的传承，但一个最本质的区别就在于Smart endpoints and dumb pipes，或者说是真正的分布式的、去中心化的。Smart endpoints and dumb pipes本质就是去ESB，把所有的“思考”逻辑包括路由、消息解析等放在服务内部（Smart endpoints），去掉一个大一统的ESB，服务间轻（dumb pipes）通信，是比SOA更彻底的拆分。

微服务相比于SOA更加精细，微服务更多的以独立的进程的方式存在，互相之间并无影响。 如果一句话来谈SOA和微服务的区别，即微服务不再强调传统SOA架构里面比较重的ESB企业服务总线，同时SOA的思想进入到单个业务系统内部实现真正的组件化。

微服务提供的接口方式更加通用化，例如HTTP RESTful方式，各种终端都可以调用，无关语言、平台限制。

微服务更倾向于分布式去中心化的部署方式，在互联网业务场景下更适合。

微服务与SOA有很多相同之处。两者都属于典型的、包含松耦合分布式组件的系统结构。在围绕着服务的概念创建架构这一方面，微服务提供了一种更清晰、定义更良好的方式。微服务的原则与敏捷软件开发思想是高度一致的，而它与SOA原则的演化的目标也是相同的，则减少传统的企业服务总线开发的高复杂性。两者之间最关键的区别在于，微服务专注于以自治的方式产生价值。但是两种架构背后的意图是不同的：SOA尝试将应用集成，一般采用中央管理模式来确保各应用能够交互运作。微服务尝试部署新功能，快速有效地扩展开发团队。它着重于分散管理、代码再利用与自动化执行。

微服务的优势有：开发简单；技术栈灵活；服务独立无依赖；独立按需扩展；可用性高。

劣势包括：多服务运维难度；系统部署依赖；服务间通信成本；数据一致性；系统集成测试；重复工作；性能监控。

 

三、怎么用

微服务架构需要解决四个问题。

3.1、客户端对服务的调用

一般在后台N个服务和客户端之间一般会一个代理或者叫API Gateway，他的作用包括：提供统一服务入口，让微服务对前台透明；聚合后台的服务，节省流量，提升性能；提供安全，过滤，流控等API管理功能。

3.2、服务间通信

同步调用：REST（JAX-RS，Spring Boot）；RPC（Thrift, Dubbo）

同步调用比较简单，一致性强，但是容易出调用问题，性能体验上也会差些，特别是调用层次多的时候。

异步消息调用：消息队列(Kafka, Notify, MetaQ)

异步消息的方式在分布式系统中有特别广泛的应用，他既能减低调用服务之间的耦合，又能成为调用之间的缓冲，确保消息积压不会冲垮被调用方，同时能 保证调用方的服务体验，继续干自己该干的活，不至于被后台性能拖慢。不过需要付出的代价是一致性的减弱，需要接受数据最终一致性；还有就是后台服务一般要 实现幂等性，因为消息发送出于性能的考虑一般会有重复（保证消息的被收到且仅收到一次对性能是很大的考验）；最后就是必须引入一个独立的broker，如 果公司内部没有技术积累，对broker分布式管理也是一个很大的挑战。

3.3、服务注册与发现

基本都是通过zookeeper等类似技术做服务注册信息的分布式管理。当 服务上线时，服务提供者将自己的服务信息注册到ZK（或类似框架），并通过心跳维持长链接，实时更新链接信息。服务调用者通过ZK寻址，根据可定制算法， 找到一个服务，还可以将服务信息缓存在本地以提高性能。当服务下线时，ZK会发通知给服务客户端。

客户端做：优点是架构简单，扩展灵活，只对服务注册器依赖。缺点是客户端要维护所有调用服务的地址，有技术难度，一般大公司都有成熟的内部框架支持，比如Dubbo。

服务端做：优点是简单，所有服务对于前台调用方透明，一般在小公司在云服务上部署的应用采用的比较多。

3.4、服务的高可用

保证服务的高可用，一般有如下途径：重试机制；限流；熔断机制；负载均衡；降级（本地缓存）

 

四、深入研究方向

4.1、微服务架构中职能团队的划分

4.2、微服务的去中心化治理

4.3、微服务的交互模式

4.4、微服务的分解和组合模式

4.5、微服务的容错模式

4.6、微服务的粒度

https://blog.csdn.net/qiansg123/article/details/80131044

 

五、面试点

5.1、微服务和SOA的爱恨情仇前世今生

5.2、微服务能够解决的问题和架构本身带来的问题及解决方案