微服务-笔记

参考： https://www.jianshu.com/p/383bace53bae

一、基本思想

围绕业务领域组件来创建应用，让应用可以独立的开发、管理和加速。

微服务中的“微”非常具有欺骗性，事实上它没有规定服务的规模有多小或多大。

这里的重点是每个独立服务都有一个业务边界，可以独立开发、测试、部署、监控和扩展，甚至可以用不同的编程语言开发它们。

在基于微服务的架构中，每个组件或服务都有自己的数据库。没有集中式数据库。

 

二、设计原则

2.1 前后端分离

2.2 无状态服务

2.3 Restful 通信风格

说明：无状态服务，是要把这个状态往外移，将 Session 数据，文件数据，结构化数据保存在后端统一的存储中，从而应用仅仅包含业务逻辑。使得整个业务就分两部分，一个是无状态的部分，一个是有状态的部分。

无状态的部分能实现两点，一是跨机房随意地部署，也即迁移性，一是弹性伸缩，很容易地进行扩容；有状态的部分，如 DB，Cache，ZooKeeper 有自己的高可用机制，要利用到他们自己高可用的机制来实现这个状态的集群。

虽说无状态化，但是当前处理的数据，还是会在内存里面的，当前的进程挂掉数据，肯定也是有一部分丢失的，为了实现这一点，服务要有重试的机制，接口要有幂等的机制，通过服务发现机制，重新调用一次后端服务的另一个实例就可以了。

 

三、微服务拆分的规范

前提：微服务拆分之后，工程会比较的多，如果没有一定的规范，将会非常混乱，难以维护。

人们经常问的一个问题是，服务拆分之后，原来都在一个进程里面的函数调用，现在变成了 A 调用 B 调用 C 调用 D 调用 E，会不会因为调用链路过长而使得调用相应变慢呢?

规范一：服务拆分最多三层，两次调用

纵向的拆分最多三层：

• 基础服务层：用于屏蔽数据库，缓存层，提供原子的对象查询接口。有了这一层，当数据层做一定改变的时候，例如分库分表，数据库扩容，缓存替换等。对于上层透明，上层仅仅调用这一层的接口，不直接访问数据库和缓存。
• 组合服务层：这一层调用基础服务层，完成较为复杂的业务逻辑，实现分布式事务也多在这一层。
• Controller 层：接口层，调用组合服务层对外。

规范二：仅仅单向调用，严禁循环调用

微服务拆分后，服务之间的依赖关系复杂，如果循环调用，升级的时候就很头疼，不知道应该先升级哪个，后升级哪个，难以维护。

层次之间的调用规定如下：

• 基础服务层：主要做数据库的操作和一些简单的业务逻辑，不允许调用其他任何服务。
• 组合服务层：不允许调用 Controller 层服务。
• Controller 层：可以调用组合业务层服务，不允许被其他服务调用。

规范三：将串行调用改为并行调用，或者异步化

当组合下发流程很长时，用消息队列实现异步化和解耦。

规范四：接口应该实现幂等

设计一个幂等表 有唯一标识

用一个状态来记录变化。如果状态已经变化则不再更新

规范五：接口数据定义严禁内嵌，透传

当数据结构中添加或者删除一个字段的时候，波及的面会非常大

这样接口数据定义的改变，影响面仅仅在调用方和被调用方，当接口需要更新的时候，比较可控，也容易升级。

规范六：规范化工程名

 

四、微服务架构优缺点

一体化架构顾名思义，将应用各层打成一个包来部署。为了让代码正常工作，一体化应用的所有组件缺一不可。

 

 

 

微服务架构带来的问题：

       依赖服务变更很难跟踪，其他团队的服务接口文档过期怎么办?依赖的服务没有准备好，如何验证我开发的功能。

       部分模块重复构建，跨团队、跨系统、跨语言会有很多的重复建设。

       微服务放大了分布式架构的系列问题，如分布式事务怎么处理?依赖服务不稳定怎么办?

       运维复杂度陡增，如：部署物数量多、监控进程多导致整体运维复杂度提升。

       上面这些问题我们应该都遇到过，并且也会有一些解决方案，比如提供文档管理、服务治理、服务模拟的工具和框架; 实现统一认证、统一配置、统一日志框架、分布式汇总分析; 采用全局事务方案、采用异步模拟同步;搭建持续集成平台、统一监控平台等等。

 

五、数据库设计

       数据库设计是微服务设计的一个关键点，基本原则是每个微服务都有自己单独的数据库，而且只有微服务本身可以访问这个数据库。微服务之间的数据共享可以通过服务调用，或者主、从表的方式实现。在共享数据时，要找到合适的同步方式，以应对逐渐增长的访问压力和数据量。

       关于数据库的扩展主要包括：业务拆分、主从复制，数据库分库与分表。

业务拆分

随着业务规模的增大，访问量的增大，我们不得不对业务进行拆分。每一个模块都使用单独的数据库来进行存储，不同的业务访问不同的数据库，将原本对一个数据库的依赖拆分为对4个数据库的依赖，这样的话就变成了4个数据库同时承担压力，系统的吞吐量自然就提高了。

数据库分库与分表

数据库分表可以解决单表海量数据的查询性能问题，分库可以解决单台数据库的并发访问压力问题。

数据库分表能够解决单表数据量很大的时候数据查询的效率问题，但是无法给数据库的并发操作带来效率上的提高，因为分表的实质还是在一个数据库上进行的操作，很容易受数据库IO性能的限制。

因此，如何将数据库IO性能的问题平均分配出来，很显然将数据进行分库操作可以很好地解决单台数据库的性能问题。

 

六、其他

1、微服务拆分后，服务之间的调用需要服务发现和注册中心进行维护。

2、 服务拆分以后，服务的数量非常多，如果所有的配置都以配置文件的方式放在应用本地的话，非常难以管理，可以想象当有几百上千个进程中有一个配置出现了问题，是很难将它找出来的，因而需要有统一的配置中心，来管理所有的配置，进行统一的配置下发。

在微服务中，配置往往分为几类，一类是几乎不变的配置，这种配置可以直接打在容器镜像里面，第二类是启动时就会确定的配置，这种配置往往通过环境变量，在容器启动的时候传进去，第三类就是统一的配置，需要通过配置中心进行下发。