一.今日完成

整理小课堂知识点,梳理微服务相关内容:

一、背景介绍

微服务是一种分布式系统解决方案,推动细粒度服务的使用,这些服务协同工作,且每个服务都有自己的生命周期.随着领域驱动设计,持续交付,按需虚拟化,基础设施自动化,小型自治团队,大型集群系统这些实践的流行,微服务应运而生.它不是被发明出来的,而是从现实世界中总结出来的一种趋势或模式.

二、知识剖析

1.传统的web开发方式---Monolithic

所有的功能打包在一个 WAR包里,基本没有外部依赖（除了容器）,部署在一个JEE容器（Tomcat,JBoss,WebLogic）里,包含了 DO/DAO,Service,UI等所有逻辑.

Monolithic比较适合小项目,优点:

开发简单直接,集中式管理

基本不会重复开发

功能都在本地,没有分布式的管理开销和调用开销

它的缺点也非常明显,特别对于互联网公司来说:

开发效率低:所有的开发在一个项目改代码,递交代码相互等待,代码冲突不断

代码维护难:代码功能耦合在一起,新人不知道何从下手

部署不灵活:构建时间长,任何小修改必须重新构建整个项目,这个过程往往很长

稳定性不高:一个微不足道的小问题,可以导致整个应用挂掉

扩展性不够:无法满足高并发情况下的业务需求.

整体风格（monolithic style）:一个完整应用程序（monolithic application）构建成一个单独的单元.企业级应用通常被构建成三个主要部分:客户端用户界面（由运行在客户机器上的浏览器的 HTML 页面、Javascript 组成）、数据库（由许多的表构成一个通用的、相互关联的数据管理系统）、服务端应用.服务端应用处理 HTTP 请求,执行领域逻辑（domain logic）,检索并更新数据库中的数据,使用适当的 HTML 视图发送给浏览器.服务端应用是完整的 ,是一个单独的的逻辑执行.任何对系统的改变都涉及到重新构建和部署一个新版本的服务端应用程序.

这样的整体服务（monolithic server）是一种构建系统很自然的方式.虽然你可以利用开发语基础特性把应用程序划分成类、函数、命名空间,但所有你处理请求的逻辑都运行在一个单独的进程中.在某些场景中,开发者可以在本地开发、测试应用,然后利用部署通道来保证经过正常测试的变更,发布到产品中.你也可以使用横向扩展,通过负载均衡将多个应用部署到多台服务器上.

2.微服务的内涵

微服务的目的是有效的拆分应用,实现敏捷开发和部署.

scale cube(或者成为分页分表):X轴代表运行多个负载均衡器之后运行的实例,Y轴代表将应用进一步分解为微服务 （分库）,数据量大时,还可以用Z轴将服务按数据分区(分表).

基本内涵:

分布式服务组成的系统

按照业务而不是技术来划分组织

做有生命的产品而不是项目

Smart endpoints and dumb pipes（强服务个体和弱通信）

自动化运维（DevOps）

容错

快速演化

3.微服务的特征

小型且专注于业务领域

在一个单块系统里,通常会创建一些抽象层或者模块来保证代码的内聚性,从而避免代码模块庞大臃肿重叠,彼此之间的界限难以维护.微服务将单一职责原则应用在独立的服务上,根据业务的边界来确定服务的边界.足够小即可.

自治性

一个微服务就是一个独立的实体,它可以独立地部署在PAAS(Platform As A Service)上,也可以作为一个系统进程存在.服务之间均通过网络调用进行通信,从而加强了服务间隔离性,避免紧耦合.

4.微服务优缺点

优点:

开发简单

技术栈灵活

服务独立无依赖

独立按需扩展

可用性高

缺点:

多服务运维难度

系统部署依赖

服务间通信成本

数据一致性

系统集成测试

重复工作

性能监控

三、常见问题

SOA vs Microservice

四、解决方案

Microservice是SOA的传承,一种细粒度的SOA;但最本质的区别就在于Smart endpoints and dumb pipes,或者说是真正的分布式的、去中心化的.Smart endpoints and dumb pipes本质就是去ESB(Enterprise Service Bus),把所有的“思考”逻辑包括路由、消息解析等放在服务内部（Smart endpoints）,去掉一个大一统的ESB,服务间轻（dumb pipes）通信,是比SOA更彻底的拆分.

五、代码实战

实践微服务

客户端如何访问这些服务？

服务之间如何通信？

这么多服务,怎么找?

服务挂了怎么办？

5.1客户端如何访问这些服务？

原来的Monolithic方式开发,所有的服务都是本地的,前端可以直接调用,现在按功能拆分成独立的服务,跑在独立的一般都在独立的虚拟机上的 Java进程了.客户端UI如何访问他的？后台有N个服务,前台就需要记住管理N个服务,一个服务下线/更新/升级,前台就要重新部署,这明显不服务我们 拆分的理念,特别当前台是移动应用的时候,通常业务变化的节奏更快.另外,N个小服务的调用也是一个不小的网络开销.还有一般微服务在系统内部,通常是无 状态的,用户登录信息和权限管理最好有一个统一的地方维护管理（OAuth）.

一般在后台N个服务和前端之间一般会一个代理或者叫API Gateway,为前台（通常是移动应用）提供后台服务的聚合,提供一个统一的服务出口,解除他们之间的耦合,不过API Gateway也有可能成为单点故障点或者性能的瓶颈.其作用包括:

提供统一服务入口,让微服务对前台透明

聚合后台的服务,节省流量,提升性能

提供安全,过滤,流控等API管理功能

5.2服务之间如何通信？

因为所有的微服务都是独立的Java进程,跑在独立的虚拟机上,所以服务间的通行就是IPC（inter process communication）,已经有很多成熟的方案.现在基本最通用的有两种方式.

同步调用

REST（JAX-RS,Spring Boot）

RPC（Thrift, Dubbo）

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

一般同步调用比较简单,一致性强,但是容易出调用问题,性能体验上也会差些,特别是调用层次多的时候.RESTful和RPC的比较也是一个很有意思的话题.一般REST基于HTTP,更容易实现,更容易被接受,服务端实现技术也更灵活些,各个语言都能支持,同时能跨客户端,对客户端没有特殊的要求,只要封装了HTTP的SDK就能调用,所以相对使用的广一些.RPC也有自己的优点,传输协议更高效,安全更可控,特别在一个公司内部,如果有统一个 的开发规范和统一的服务框架时,开发效率优势更明显些.

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

5.3这么多服务,怎么找?

在微服务架构中,一般每一个服务都是有多个拷贝,来做负载均衡.一个服务随时可能下线,也可能应对临时访问压力增加新的服务节点.服务之间如何相互感知？服务如何管理？这就是服务发现的问题了.

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

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

5.4这么多服务,服务挂了怎么办?

分布式最大的特性就是网络是不可靠的.通过微服务拆分能降低这个风险,相应的手段有很多:

重试机制

限流

熔断机制

负载均衡

降级（本地缓存）

六、扩展思考

微服务的前景:

对于大的互联网公司,微服务架构是血液,是习惯,每家公司都有自己的套路和架构,细节有不同,但是核心理念是通的.

对于一般的公司而言,实践微服务有非常大的技术挑战,于是乎才有了这么多IT供应商考虑这里的商机.微服务比较适合未来有一定的扩展复杂度,且有很大用户增量预期的应用,说人话就是新兴的互联网公司.创业初期,不可能买大量的机器或者很贵的机器,但是又必须考虑应对成功后的巨量的用户,微服务架构 成了最好的选择.

二.明日计划

整理文学部方案设计文本.

三.遇到问题

暂无.

四.收获

以上: