? 首先讲到单体应用架构，何所谓单体应用架构，在互联网开始阶段，一个系统的所有?？槎技性谝黄?，并以jar包的方式统一部署在服务器上。这样做有两个比较明显的问题：1.所有?？榧性谝黄?，没有实现模块的解耦，一次小小的改动将可能影响其他模块；在发版的时候也麻烦，每次发版都需要一个发版负责人列出发版清单并跟每个开发人员确定每个需求代码的合并情况，防止代码合并遗漏，有时候解决合并代码的冲突问题，还得来回确定。一个版本要经过很长的时间来回确认代码的合并正确性。2.发布成功后，在后台运行过程中，因为一个?？榈奈侍猓贾抡鱿低吵鑫侍?。例如：版本上线运行一段时间，一个?？橐虼罅可昵肽诖?，导致内存不够用而使该?？槌鑫侍?。从而导致整体系统不能对外提供服务。

基于以上两个问题，后来就演进了微服务架构。在微服务之前，先说下服务化，服务化就是根据业务规则对系统进行独立拆分，使各个服务保持相对独立并通过RPC接口（远程调用）进行服务间通讯。通过服务化很好的解决了单体应用中?？榍狂詈系奈侍?。

在2014年随着Docker技术和Devlop文化的发展，又演进了微服务化。微服务化相对于服务化来说，拆分粒度更小，更细。实现微服务有4个典型特征：

1.拆分粒度更小了?？梢运滴⒎窬褪欠窕?，更细粒度的拆分。

2.服务独立部署。各个服务独立打包并部署，不会影响到其他服务

3.服务独立维护。服务的上线，下线相对独立，不会影响其他服务。

4.服务治理能力高。随着微服务越来越多，需要一个更大的平台来综合管理各个服务。可以想象下，一堆的服务摆在那里而无法管理是一个什么样的场景。

把单体应用拆分为微服务必须面临的几个问题：

1.服务如何拆分？服务之间的如何通讯？

服务一般按业务模块（横向拆分）和公众功能?？椋ㄗ菹虿鸱郑┙胁鸱?，前者是把业务上相关联的模块合并独立成一个微服务，业务上差异比较大的拆分开来。后者是业务的公共部分进行拆分。例如在电商系统中，用户?？?，订单模块，商品?？槎蓟嵊玫接没畔?，就可以把用户?？榈ザ啦鸱忠桓龆懒⒌挠没е行姆?。

服务间的通讯一般是通过接口，这个接口一般有RPC，RESTapi等方式。

2.服务如何发布部署？

需要服务注册，服务发现流程。在微服务架构中就是服务注册中心。

3.服务如何监控？

通过日志记录，埋点等全链路功能来监控服务的每一个流程。

4.服务如何治理？

服务数量多了，依赖也增多了，一般通过熔断来解决服务治理问题。

5.服务如何定位？

一般通过服务跟踪系统来定位问题。如阿里的“鹰眼”

微服务基本组件部分：

1.服务描述：服务对外描述，从服务的如何调用，输入什么参数，返回什么结果等形式，一般有REST api，XML文件配置和接口描述语言（IDL）等方式

2.注册中心：服务等发布和订阅，主要解决如何让外部的人员知道服务的问题。

3.服务框架：服务消费者和服务提供者之间通讯机制或流程。主要是通讯协议和数据传输的定义

3.服务监控：需要监控服务消费者和提供者。确定服务是否正常。（指标收集（如微服务接口调用次数，请求耗时时间），数据处理，数据展示）

4.服务追终。记录服务每一个环节和层次，方便对服务进行定位问题。

5.服务治理：通过一系列手段解决微服务问题。

服务描述的三种方式：

1.RESTapi 一般通过HTTP或HTPPS协议调用服务

2.XML 配置：1.服务提供者定义接口并实现接口；2.部属服务并对外发布；3.服务消费者订阅服务并调用服务。其实就是web Servers方式。

3.接口描述语言（IDL），用于垮语言调用，如java 调用C++。一般有两个FaceBook的协议，和google的JRPC协议，即protocol Buffer协议。

注册和发现服务：

注册中心：把部署服务的地址注册到注册中心，实现服务的统一注册和订阅。分布式集群部署，通过zoonKeeper实现服务的统一和数据的一致性。

服务监控：

1.监控对象，

? 1.1.用户端监控

? 1.2.接口监控，如：RPC 接口

? 1.3.资源监控：对数据库的连接，对Redies的使用监控

? 1.4.基础监控，对服务器的健康状态系统监控，如CPU，内存，网卡带宽情况

2.监控需要有哪些指标

2.1.请求量：

? 实时请求量

? 统计请求量（PV）

2.2.响应时间：平均耗时

2.3.错误率：一段时间内调用失败的次数与总数的比例

3.监控的维度：

? 1.全局维度。对监控对象的指标进行监控，如从全局的范围内监控RPC接口的调用错误率。

? 2.分机房维度。从某一个机房维度，看监控对象（数据库连接）的响应时间。

? 3.单机维度。从一台服务器的维度来看监控对象（用户端监控，业务调用）对统计请求量（PV）是多少。

? 4.时间维度。不同时间的指标对比。

? 5.核心维度与非核心维度的调用情况。

监控系统4个环节：

1.数据采集：

? 1.1.主动上报：每次服务完成后，主动上报数据信息（服务调用者，调用那个服务，调用时间，响应请求）。

? 1.2.代理方式：相关日志记录在本地，并通过代理方式上报给日志中心

2.数据传输

? 2.1.UDP传输

? 2.2.kafka消息队列传输

3.数据处理

? 3.1.接口维度

? 3.2.从单机维度处理

4.数据展示。

服务追踪：

通过记录每个链路点的日志信息（包括响应时间），可以追踪每个服务的情况。从全局角度观察，找出系统瓶颈点。改进瓶颈点，也就提高了系统性能。

服务治理：

1.节点管理：

? 1.1.注册中心摘除出问题的服务，

? 1.2.服务提供者自己摘除出问题的服务

2.负载均衡

2. 1.随机算法（平均分布）

? 2.轮训算法

? 3.最少活跃度算法（连接一次权重加1）

? 4.一致性hash算法

3.服务路由，建立路由规则

? 静态配置：保存在本地

? 动态配置：请求后更新

最后推荐下最佳实践：阿里开源的Dubbo 服务框架