一、分布式和微服务架构的定义

分布式应用场景涵盖的面十分广，我了解的局部：

• 不同过程之间的相互通信，
• 不同主机的分布式对象之间调用，
• 用于大数据存储的分布式文件系统，
• 用于网络之间互相辨认的命名服务，
• 集群中计算或存储的无核心对等模型，
• 分布式事务，
• 数据正本在分布式环境中的复制，
• 云计算服务，
• 音视频在网络中的点播和传输
• ….

微服务架构的目标是对原来过于大而重的云应用服务进行解耦，伎俩是进行比拟正当的业务模块拆解，拆解的粒度往往由架构师把握，实现细粒度的服务，服务在云端造成分布式状态。

那么微服务就具备了分布式的一些利用场景，比方：不同主机的分布式对象之间调用，以前 EJB 用 RMI（近程办法调用），当初微服务罕用 RPC（近程过程调用）；再比方：用于网络之间互相辨认的命名服务，以前 EJB 是 JNDI 命名服务，当初 SpringCloud 的 Euraka 用于微服务的注册和发现，也是分布式是命名服务。

如何艰深地了解「分布式系统」，它解决了哪些问题，有什么优缺点？

了解「分布式系统」已经产生的事件

下面是我另外一个答复，外面比拟具体地形容了历史上过来 EJB 和 Spring 的比拟，也是分布式与单体利用的比拟。那时候 EJB 代表分布式服务，而 spring 代表单体服务。

下面的图简略的描述了一种最简略的单体服务向微服务拆解的过程。当然微服务面临的挑战不仅仅这么简略，这只是微服务的一种比拟初始的状态。

二、分布式和微服务这两者解决了什么问题

分布式是计算、服务、存储在网络中相互交换与合作的模式和状态

分布式到底解决了什么？

上图就是典型的分布式计算，一个大文件被切分成四份，MapReduce 分成四个工作（过程），而后在同一主机不同过程，或不同主机上进行数据处理，最终再通过网络汇聚到一个合并工作。那么这个时候到分布式就是工作并行，解决了单任务的效率问题。

上图是个典型的分布式状态协调治理图，是 Hadoop HDFS 集群的 HA 高可用架构，主副两个 Namonode 节点，必须活着一个，当判断主的挂了，必须让副的顶上去，这个时候，三个 ZK（zookeeper）组成的集群就是作为主副节点的协调者，通过 ZKFC 过程实现对 Namoenode 节点的心跳监控和切换命令下发。

另外三个 Journalnode 节点造成的集群又是 namonode 分布式状态数据保留的中央，当主 namonode 挂了，所有的状态必须疾速的复原到副 namenode 的下面，所以 Journalnode 必须继续同步状态，满足 hdfs 集群状态的疾速复原

那么分布式中十分要害的一个利用场景——集群，上述的 Hadoop hdfs 集群，就须要有一个或几个角色(zookeeper，Journalnode)，作为集群状态的协调者和管理者。有时候这种状态治理是对等的(GlusterFS)，有时候这种状态治理是集中的（Hadoop 就是这样）。

微服务又解决了什么问题呢？

如果这时候在提微服务的分布式劣势，就不是目标，而是伎俩了。微服务只是借助了分布式架构，达到了本人的目标。所以微服务不是根底技术架构的问题，而是下层利用的架构问题。

下面的例子是个简略的互联网医疗服务单体利用，这时候问诊、药品、订单、即时消息都是互联网医疗最外围的业务，信息推送目标是将互联网医疗平台的各类信息进行互联网信息服务平台的推送、公布和交换，达到自我推广的目标。

可恰好信息推送服务的更新水平很高，因为须要对外连贯的互联网服务平台状况简单，也会有新的服务平台纳入到模块范畴，那么作为单体利用就存在这样一个部署问题，每次更新一个新的信息推送性能，就要整体服务重新部署一次，那么这种影响对于外围服务就造成了很大的困扰，这时候的患者、医生、医院的业务影响都是大规模的。

再看看微服务架构，如果将信息推送服务作为独自的微服务存在，其余微服务只是将须要推送到互联网服务平台的内容进行近程调用即可，甚至用音讯核心的形式，打包成音讯，实现音讯事件驱动，让对外公布服务的部署不会干涉到其余外围服务，使得整体平台因为部署公布而造成的影响降到最低。这种形式是不是看起来就难受多了，十分利于部署、公布，甚至加强了整体零碎的鲁棒性。

当然微服务解决的问题还有很多，团队分工的细粒度、迭代速度的晋升、更易于小范畴重构，利于继续化集成 (devops) 等等，就不一一具体形容了，只把它很有特点的局部拿进去了解一下。

三、这些架构带来的利弊

分布式对应的是就是单机，其长处上节形容了一些，就不赘述了，毛病也很大
部署不简略，运维不简略
网络瓶颈和故障会有重要的影响，
节点若生效，就要有觉察和热替换机制，
一致性问题，例如分布式事务始终是世界性难题，
不仅要思考平衡负载，更要思考平衡负载的成果。
数据进行分布式存储，在有些对等模式下还要思考数据歪斜问题。
微服务除了分布式存储毛病 6 之外，上述前 5 个毛病基本上都完满的继承了。

四、利用不当所带来的技术债权

说说微服务设计不当的麻烦问题吧

（1）微服务解耦后，会将一些业务程序从原来数据库查问的形式，转变成近程对象调用，这个过程我在原来的答复中提过，这是反兽性的。造成复杂度和须要约定的接口都带来了比 SQL 查问更大的工作量。而且更反兽性的形式就是数据库也跟着微服务进行分库，到底哪些数据须要冗余，哪些数据还能放弃数据库范式，根本都能把高程们烦死。

（2）教训欠缺的微服务架构师，容易将微服务切得太细，如果一个单体若被切分成一千个微服务，而且微服务之间用到了近程对象序列化和反序列化，那么这就成了死穴！因为一旦一个微服务的实体对象进行了调整，那么有多少个关联的微服务被净化了，就要一直定位其余微服务的依赖关系并从新公布，这种工作量曾经超出了本该解决业务问题的工作量。

因而微服务的划分肯定要留神，而且 RPC 之间的对象传递尽量用简略、涣散的构造来做。微服务划分的水平依据业务不同而粒度不同，有种约定是一个微服务进行大的重构，须要一周的工夫，做为微服务粒度规范。

五、我的项目间接应用微服务架构, 是基于对将来的思考？

微服务架构的思考，不应该是对将来的思考，而是对过来单体式利用呈现问题后的一种架构重构，从第一节中的图能够看到其重构过程，在互联网医疗的例子中微服务的重构进一步趋向于音讯驱动、事件驱动。

从以往施行微服务的经验教训中，我总结进去的教训，如果是新我的项目的架构师，能够先抉择单体利用，而后依据业务倒退一点点迭代重构到微服务上来，即使过程中微服务的架构不那么纯正，甚至单体利用和微服务很长一段时间共存，也要谨慎从新的我的项目上间接去设计微服务。

因为谁也不是算命先生，能估算到本人业务零碎会在哪一天，哪个层面，哪个范畴就肯定须要微服务化解耦。只有零碎运行快到那个阶段了，能力让架构师更容易做到正当的微服务化决策。当然了，也有人会有纳闷，零碎设计成单体，谁还有心理持续重构微服务，不如间接做成微服务架构多省事，而我想说的是，若无重构之力行，切勿有微服务之念想。

六、K8s 和 Spring Cloud 有什么区别和分割?

Spring Cloud 是贯彻微服务架构的一种具体实现框架，包含了 springboot 作为微服务的独立运行容器，Euraka 作为微服务的注册和发现，zuul 服务网关，其余的没怎么用，就不提，其实网关我更喜爱用 Openresty。

k8s 只是容器的一种编排框架，管理者大量的 docker 容器，然而当初 k8s 又不集成 docker 了，晕得很！

docker 作为微服务的容器，为每一个微服务都提供了独自的网络、文件系统、过程治理等基础设施，这样每个微服务的状态、运行日志能够更好的被监控和治理。另外容器让部署过程变得简略，促成了当初风行的 devops 开发、公布、部署一体的管理模式，微服务的容器化其实是天生一对。

七、结尾

当咱们了解分明分布式下的各种场景是什么的一种存在模式的时候，当咱们了解微服务又是一种什么分布式场景的时候，咱们就更能分明的去做好微服务的设计决策。

返回读字节的知乎——理解更多对于大数据的常识

公众号“读字节”分布式，大数据，软件架构的深度，业余解读