微服务概述
<h2>一、什么是微服务</h2>
<ol>
<li>
<p>一组小的服务（大小没有特别的标准，只要同一团队的工程师理解服务的标识一致即可）</p>
</li>
<li>
<p>独立的进程（java的tomcat，nodejs等）</p>
</li>
<li>
<p>轻量级的通信（不是soap，是http协议）</p>
</li>
<li>
<p>基于业务能力（类似用户服务，商品服务等等）</p>
</li>
<li>
<p>独立部署（迭代速度快）</p>
</li>
<li>无集中式管理（无须统一技术栈，可以根据不同的服务或者团队进行灵活选择）</li>
</ol>
<h2>二、怎么权衡微服务的利于弊</h2>
<h3>利：</h3>
<ul>
<li>
<p>强模块边界 。（模块化的演化过程：类-->组件/类库（sdk）-->服务(service)，方式越来越灵活）</p>
</li>
<li>
<p>可独立部署。</p>
</li>
<li>技术多样性。</li>
</ul>
<h3>弊：</h3>
<ul>
<li>
<p>分布式复杂性。</p>
</li>
<li>
<p>最终一致性。（各个服务的团队，数据也是分散式治理，会出现不一致的问题）</p>
</li>
<li>
<p>运维复杂性。</p>
</li>
<li>测试复杂性。</li>
</ul>
<h2>三、企业在什么时候考虑引入微服务</h2>
<p>从生产力和系统的复杂性这两个方面来看。公司一开始的时候，业务复杂性不高，这时候是验证商业模式的时候，业务简单，用单体服务反而生产力很高。随着公司的发展，业务复杂性慢慢提高，这时候就可以采用微服务来提升生产力了。至于这个转化的点，需要团队的架构师来进行各方面衡量</p>
<h2>四、微服务的组织架构</h2>
<p><img src="https://www.showdoc.cc/server/api/common/visitfile/sign/2b17c097807270e29079da8945bd6a38?showdoc=.jpg" alt="" /></p>
<p>如上图左边，传统的企业中，团队是按职能划分的。开发一个项目时，会从不同的职能团队找人进行开发，开发完成后，再各自回到自己的职能团队，这种模式实践证明，效率还是比较低的。</p>
<p>如上图右边，围绕每个业务线或产品，按服务划分团队。团队成员从架构到运维，形成一个完整的闭环。一直围绕在产品周围，进行不断的迭代。不会像传统的团队一样离开。这样开发效率会比较高。至于这种团队的规模，建议按照亚马逊的两个披萨原则，大概10人左右比较好。</p>
<h2>五、怎么理解中台战略和微服务</h2>
<p>中台战略的由来：马云2015年去欧洲的一家公司supersell参观，发现这个公司的创新能力非常强，团队的规模很小，但是开发效率很高。他们就是采用中台战略。马云感触很深，回国后就在集团内部推出了中台战略。</p>
<p><img src="https://www.showdoc.cc/server/api/common/visitfile/sign/fea611d7fb18ae5bedf956f85946ef4d?showdoc=.jpg" alt="" /></p>
<p>简单的理解就是把传统的前后台体系中的后台进行了细分。阿里巴巴提出了大中台小前台的战略。就是强化业务和技术中台，把前端的应用变得更小更灵活。当中台越强大，能力就越强，越能更好的快速响应前台的业务需求。打个比喻，就是土壤越肥沃，越适合生长不同的生物，打造好的生态系统。</p>
<h2>六、服务分层</h2>
<p>每个公司的服务分层都不相同，有的公司服务没有分层，有的分层很多。目前业界没有统一的标准。</p>
<p>下面推荐一个比较容易理解的两层结构。
<img src="https://www.showdoc.cc/server/api/common/visitfile/sign/7b8ef10d925947598f57238f2a8b4c16?showdoc=.jpg" alt="" /></p>
<ol>
<li>
<p><strong>基础服务</strong>： 比如一个电商网站，商品服务和订单服务就属于基础服务（核心领域服务）。缓存服务，监控服务，消息队列等也属于基础服务（公共服务）</p>
</li>
<li><strong>聚合服务</strong> ：例如网关服务就算一种聚合服务（适配服务）。</li>
</ol>
<p>这是一种逻辑划分，不是物理划分，实际设计的东西很多很复杂。</p>
<h2>七、微服务的技术架构体系</h2>
<p>下图是一个成型的互联网微服务的架构体系：</p>
<p><img src="https://www.showdoc.cc/server/api/common/visitfile/sign/ef5b37d722b4a65165336da3d194ed6b?showdoc=.jpg" alt="" /></p>
<ol>
<li>
<p><strong>接入层</strong> 负载均衡作用，运维团队负责</p>
</li>
<li>
<p><strong>网关层</strong> 反向路由，安全验证，限流等</p>
</li>
<li>
<p><strong>业务服务层</strong> 基础服务和领域服务</p>
</li>
<li>
<p><strong>支撑服务层</strong></p>
</li>
<li>
<p><strong>平台服务</strong></p>
</li>
<li><strong>基础设施层</strong> 运维团队负责</li>
</ol>
<h2>八、微服务的服务发现的三种方式</h2>
<p>第一种：如下图所示，传统的服务发现（大部分公司的做法）。服务上线后，通知运维，申请域名，配置路由。调用方通过dns域名解析，经过负载均衡路由，进行服务访问。缺点： LB的单点风险，服务穿透LB，性能也不是太好</p>
<p><img src="https://www.showdoc.cc/server/api/common/visitfile/sign/72692df942baeae2976b78ad9823f95f?showdoc=.jpg" alt="" /></p>
<p>第二种：也叫客户端发现方式。如下图所示。通过服务注册的方式，服务提供者先注册服务。消费者通过注册中心获取相应服务。</p>
<p>并且把LB的功能移动到了消费者的进程内，消费者根据自身路由去获取相应服务。优点是，没有了LB单点问题，也没有了LB的中间一跳，性能也比较好。但是这种方式有一个非常明显的缺点就是具有非常强的耦合性。针对不同的语言，每个服务的客户端都得实现一套服务发现的功能。</p>
<p><img src="https://www.showdoc.cc/server/api/common/visitfile/sign/c2dd241ad01f44656dccc3b5955641d9?showdoc=.jpg" alt="" /></p>
<p>第三种：也叫服务端发现方式，如下图所示。和第二种很相似。但是LB功能独立进程单独部署，所以解决了客户端多语言开发的问题。唯一的缺点就是运维成比较高，每个节点都得部署一个LB的代理，例如nginx。</p>
<p><img src="https://www.showdoc.cc/server/api/common/visitfile/sign/dd1d25e92cdfac3144f63bf78f4d5572?showdoc=.jpg" alt="" /></p>
<h2>九、微服务API网关</h2>
<p>网关就好比一个公司的门卫。屏蔽内部细节，统一对外服务接口。</p>
<p><img src="https://www.showdoc.cc/server/api/common/visitfile/sign/3f59eea12018aca75f7759e980e83982?showdoc=.jpg" alt="" /></p>
<p>下图是一个网关所处位置的示例图。</p>
<p><img src="https://www.showdoc.cc/server/api/common/visitfile/sign/70ff4b6375311c570fef9ef5275f419c?showdoc=.jpg" alt="" /></p>
<h2>十、微服务的路由发现体系</h2>
<p>整个微服务的路由发现体系，一般由服务注册中心和网关两部分组成。如下图所示，首先外部请求发送到网关，网关去服务注册中心获取相应的服务，进行调用。其次内部服务间的调用，也通过服务注册中心进行的</p>
<p><img src="https://www.showdoc.cc/server/api/common/visitfile/sign/25a1e23d54da1f7d4f4e03c29cab0a3b?showdoc=.jpg" alt="" /></p>
<h2>十一、微服务配置中心</h2>
<p>目前大部分公司都是把配置写到配置文件中，遇到修改配置的情况，成本很高。并且没有修改配置的记录，出问题很难追溯。配置中心就接解决了以上的问题。</p>
<p>可配置内容：数据库连接，业务参数等等</p>
<p>配置中心就是一个web服务，配置人员通过后台页面修改配置，各个服务就会得到新的配置参数。实现方式主要有两种，一种是push，另一种是pull。两张方式各有优缺点。push实时性较好，但是遇到网络抖动，会丢失消息。pull不会丢失消息但是实时性差一些。大家可以同时两种方式使用，实现一个比较好的效果。如下图所示，这是一个国内知名互联网公司的配置中心架构图。</p>
<p><img src="https://www.showdoc.cc/server/api/common/visitfile/sign/1ad1b884f723a75a60110913498a106d?showdoc=.jpg" alt="" /></p>
<h2>十二、RPC遇到了REST</h2>
<p><img src="https://www.showdoc.cc/server/api/common/visitfile/sign/88d28f369dfe27f588b0e6426f325132?showdoc=.jpg" alt="" /></p>
<p>内部一些核心服务，性能要求比较高的可以采用RPC，对外服务的一般可以采用rest</p>
<h2>十三、服务框架和治理</h2>
<p>微服务很多的时候，就需要有治理了。一个好的微服务框架一般分为以下14个部分。如下图所示。这就是开篇所说的，微服务涉及的东西很多，有些初创公司和业务不成熟的产品是不太适合的，成本比较高。
<img src="https://www.showdoc.cc/server/api/common/visitfile/sign/707bd1da0225a18585e85ab259845039?showdoc=.jpg" alt="" /></p>
<h2>十四、监控体系</h2>
<p><img src="https://www.showdoc.cc/server/api/common/visitfile/sign/c107fe0de8406c2292f24f48e6ceaa89?showdoc=.jpg" alt="" /></p>
<p>监控的内容分为五个部分：日志监控，Metrics监控（服务调用情况），调用链监控，告警系统和健康检查。</p>
<p>日志监控，国内常用的就是ELK+kakfa来实现。健康检查和Metrics，像spring boot会自带。Nagios也是一个很好的开源监控框架。</p>
<h2>十五、Trace调用链监控</h2>
<p><strong>调用链监控是用来追踪微服务之前依赖的路径和问题定位</strong></p>
<p>下图是目前比较流行的调用链监控框架</p>
<p><img src="https://www.showdoc.cc/server/api/common/visitfile/sign/13d27b5e9b017697fb1c8bb89d58495b?showdoc=.jpg" alt="" /></p>
<h2>十六、微服务的限流熔断</h2>
<p>假设服务A依赖服务B和服务C，而B服务和C服务有可能继续依赖其他的服务，继续下去会使得调用链路过长。如果在A的链路上某个或几个被调用的子服务不可用或延迟较高，则会导致调用A服务的请求被堵住，堵住的请求会消耗占用掉系统的线程、io等资源，当该类请求越来越多，占用的计算机资源越来越多的时候，会导致系统瓶颈出现，造成其他的请求同样不可用，最终导致业务系统崩溃。</p>
<p>一般情况对于服务依赖的保护主要有两种方式：<strong>熔断和限流</strong>。</p>
<p>下图是Hystrix的断路器原理图
<img src="https://www.showdoc.cc/server/api/common/visitfile/sign/212be600a88b8299050f77a5645b8ff2?showdoc=.jpg" alt="" /></p>
<h2>十七、Docker容器部署技术&持续交付流水线</h2>
<p>随着微服务的流行，容器技术也相应的被大家重视起来。容器技术主要解决了以下两个问题：</p>
<ol>
<li>
<p><strong>环境一致性问题。</strong>例如java的jar/war包部署会依赖于环境的问题（操着系统的版本，jdk版本问题）。</p>
</li>
<li><strong>镜像部署问题。</strong>例如java，rubby，nodejs等等的发布系统是不一样的，每个环境都得很麻烦的部署一遍，采用docker镜像，就屏蔽了这类问题。</li>
</ol>
<p>下图是Docker容器部署的一个完整过程。</p>
<p><img src="https://www.showdoc.cc/server/api/common/visitfile/sign/104bf4a6dc559c10b0841e8999a1bd77?showdoc=.jpg" alt="" /></p>
<h2>十八、容器调度和发布体系</h2>
<p>目前基于容器的调度平台有Kubernetes，mesos，omega。下图是Kubernetes的一个总架构示意图
<img src="https://www.showdoc.cc/server/api/common/visitfile/sign/88561d79be7d935f1c142d7b03f60098?showdoc=.jpg" alt="" /></p>
<p>下图是一个完整的容器发布体系</p>
<p><img src="https://www.showdoc.cc/server/api/common/visitfile/sign/2278956ba171de04321f26300ab89f45?showdoc=.jpg" alt="" /></p>
<h2>十九、nisbos平台初步规划的微服务整体架构图</h2>
<p><img src="https://www.showdoc.cc/server/api/common/visitfile/sign/b1a0c16fb0624770bc168c1d4b08af85?showdoc=.jpg" alt="" /></p>