开发者学堂课程【Spring Cloud 微服务架构设计与开发实战 ：1.7微服务架构 Microservice 的设计策略】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：/learning/course/60/detail/1111
1.7微服务架构 Microservice 的设计策略
内容介绍
一、 微服务 Microservice 的设计原则
二、 微服务 Microservice 的拆分原则
三、 微服务 Microservice 设计的关注点
四、 微服务架构的新特性
五、 微服务 Microservice 设计的五大考量
六、总结
本节课重点关注如何进行微服务架构设计。第一阶段主要偏重理论体系，即和微服务相关的整个系统的重要的概念原则，为实战练习做铺垫。学习分为三大阶段，下节课主要讲解一些经典的设计模式。
一、 微服务 Microservice 的设计原则
1、需求第一
微服务架构属于分布式架构的一种，但是微服务架构是更复杂的分布式架构。微服务架构扎根于分布式架构。微服务实际上是诞生于 SOA，所以它具备某些 SOA 架构的一些特点。
所有的架构设计都有一个重要的原则，必须以需求为出发点，这是客观的理性的尊重事实的架构的设计原则，或者是不带任何偏见的所有架构师应该遵守的架构设计原则。所有的架构好与坏是相对的，相对于它所处的需求背景或者需求点。不能直接得出架构好与坏这样的结论，而是通过比较得出结论。不能因为现阶段微服务架构是比较流行的架构就得出微服务架构是最好的结论，这样的评价不够客观理性。因为微服务架构在某些业务场景中具备优势，所以相比传统架构它有很多优点，但是也存在一些缺点。总之，所有的架构设计必须以实际需求为第一出发点，不能离开需求设计架构。
出于某些原因，一些架构师在设计架构时并不是以需求作为第一出发点，而是将某些因素作为架构设计的第一出发点。比如很多公司的小网站，招聘网站，考勤系统等既没有用户量，业务也非常稳定，但还是使用了微服务架构。这是因为架构的负责人出于生存压力的需要，要设计一个高级的架构来为自己加分。
一些架构师在设计架构时，设计的复杂难懂，在架构中运用了各种包，各种项目拆分，前后端分离，模块拆分等使得调用关系复杂，难以维护。从单个请求的角度，请求调用非常复杂而且性能严重下降。这样会使开发团队变得庞大，架构难以维护难以扩展。从另外一个角度上，这种难以维护难以扩展的足够复杂的架构能够体现出架构师的能力比较强。
2、单一职责
OOP 中有个重要的原则是单一职责，在拆分服务时也是需要服务尽量体现单一职责。
3、粒度适中
粒度不是越细越好，也不是越粗越好。一个项目只有一个服务，或者一个项目一个函数一个服务或者一个方法一个服务也不可以，粒度太细无法进行维护。
4、协议统一
尽量做到统一协议，非必须不接受其他协议。微服务目前的协议主要是 Rest，有可能会引入其他的通信协议，这都是基于实际开发的需求而引入的。
5、独立开发
模块拆分以后，开发人员按照模块拆分，每人负责一个模块。每个人熟悉一块代码和业务逻辑，这样会提高开发熟练度。
6、独立部署
独立部署是微服务架构中很重要的原则。因为微服务拆分后可能会出现很多程序进程，而且并不是每个模块都更新，只需要迭代某个模块就可以了，体现了分而治之的思想。
如果统一部署，牵扯面会很大，导致部署效率很低，影响整个系统。
在微服务架构中有提到灰度发布等等这样的概念，也是体现了独立部署分而治之的思想。
二、 微服务 Microservice 的拆分原则
微服务如何拆分也是一道面试题。拆分服务粒度太小或太大都不合适，需要一个大概的拆分粒度。
1、按照业务模块拆分
2、DDD 思路可以借鉴，不能照搬
3、单─职责 Single Responsibility
服务拆分一般是基于业务，与 DDD 原则不谋而合，DDD 是领域驱动设计。DDD 并不是架构设计模式，而是面向对象的一个设计原则思想，是用来解决复杂业务逻辑的拆分问题。DDD 本身不解决整个架构设计问题，而是针对于解决业务问题。之前删除架构，实际模块都是按照 DDD 原则拆分，体现了单一职责的理论。
4、电商架构设计: 账号模块，商品模块，订单模块，评论模块，快递模块，短信模块，支付模块，卡券模块，信用模块，酒店模块。
(1)、举例说明一：
比如在订单中，账号中，服务类都是完成订单相关的操作。一般的电商网站的架构设计比较明显，比如淘宝的拆分就比较多，支付宝，微信，拼多多，京东等拆分都比较多。订单所有的逻辑可能会微服务化，支付也是一样。支付宝某年双十一的并发量峰值达到58万，用户登录，点评，历史订单查询，信用等接口都不一样。不同微服务的业务迭代模式不同，并发量不同，存储量不同，要求也不同。
订单，双十一瞬间的搜索，支付的并发可能是非常高的。有效订单已经达到了每秒58万，搜索的并发量可能会超过百万甚至更高，用户点击购物车不一定会形成订单，所以前面可能需要更多的查询的请求压力。
每个APP客户端，比如淘宝客户端，天猫客户端，支付宝客户端可能都需要这个。淘宝推出了菜鸟统一订单的查询，淘宝需要订单查询的服务，支付宝中也会进行同步。淘宝中有酒店，飞猪等酒店模块，支付宝中也有酒店模块。支付宝中还包括社保，水电煤等众多公众模块。这种场景就像生态，接入的功能模块很多，得益于足够庞大的基础，分而治之的思想以及高并发，快速的业务迭代，微服务水到渠成，这是非常适合业务模式的架构。
(2)、举例说明二：
以上是举的电商相关的例子，社交也一样。像微信，陌陌等社交软件，陌陌的业务比微信复杂，它包含了很多功能比如支付，直播等，虽然陌陌的语音通话，视频通话等功能做的不是很好，但是其他功能很丰富。无论是微信还是其它社交 APP，从1.0版本诞生到今天都具有很明显的微服务架构。新的业务诞生早期可能只有两三台服务器，后期发展起来可能会拥有上千台服务器。
(3)、举例说明三：
很多平台游戏的前端是导流模式，加入一个模块进来把平台作为入口。
(4)、举例说明四：
抖音早期是通过直播带货将流量带给淘宝。现在是抖音做电商，交易算在抖音的平台中，会提高抖音的见微，直接影响整个平台的估值。交易量高，市值就会高。
总结拆分原则：一般是基于业务拆分也可以说是 DDD，但并不是完全照搬 DDD，不是和 DDD 完全一致的思想。DDD 中有很多其它的概念，其中，在拆分业务逻辑时 DDD 提倡业务边界。business domain 的意思是业务的范围。Domain 本身就是领域范围的意思。
三、 微服务 Microservice 设计的关注点
微服务架构的设计需要关注一个问题：为什么要进行微服务架构设计，作为微服务架构设计师，应该解决什么问题首先关注什么问题。
在设计微服务架构时需要除了考虑并发，还要考虑可用性，安全性，性能。性能一般是与高并发相关的，高并发高可用是一个典型的分布式架构，这几个关注点都会受到影响。接口的重幂性，幂等性在早期的 webservice,SOA 中已经存在。
安全性会变得更加复杂。由于微服架构设计拆分的更细，所以其中很重要的一个场景 SSO 可能也会进行扩展引入。
四、 微服务架构的新特性
1、微服务架构作为一个比较流行，比较新的架构具备如下特点：独立部署，粒度适中，服务隔离，单一职责，独立开发，边界清晰，服务自制。
(1)、服务隔离指各个微服务之间互不影响，某个服务断了或者高并发，扩容都不影响其他服务，各个服务是独立的，这也是分而治之的思想。
(2)、服务自制相当于政治上的地区自治，由于某些情况特殊所以实行自治。如果把有订单的服务，有支付的服务部署到一个进程中，某个服务出错就会影响到其他服务。把服务分开部署，清晰的体现出了服务隔离和服务自制。
(3)、如果拆分做的好，独立开发独立部署，边界清晰都不会有问题。
2、微服务的关注点：敏捷运维，敏捷开发，敏捷测试
采用微服务架构的很重要的一个点是敏捷开发，快速开发，这也是为什么要各自负责一个模块的原因。敏捷开发的本质是高效率的编程，提高生产率。
如果设计的一个架构开发完效率反而变低，说明架构一定有问题。如果某些团队公司使用完一个架构后发现效率变低，成本上升，说明该架构还存在优化的空间。很多公司，银行机构都存在这样的问题，使用的架构比较老，但是并不允许使用新架构。
五、 微服务 Microservice 设计的五大考量
1、微服务拆分
2、微服务高可用
3、微数据安全
4、微服务数据同步
5、微服务监控
在设计微服务架构时要考虑的详细。需要注意拆分微服务的粒度，如何解决服务的高可用问题。
一些人在设计架构时，拆除了数据库和服务，但是落地只有一台服务器，这样相当于没有使用微服务。一个架构师所采用的微服务架构必须能够说服别人，给出合适的理由。虽然有时候不得不使用一些不规范的架构，但是从客观角度要能够知道架构的好与坏。
微数据安全需要注意接口安全，数据安全。在微服务架构中做事务比较难，需要注意数据的隐私性问题，怎么样做数据同步。因为在微服务中拆的很多，所以监控日志就会更难做。
六、总结
本节课所讲的知识点涉及到大量面试题，需要去好好学习思考。无论是否使用微服务架构，都要知道它的好坏，了解什么时候需要拆除，什么时候不需要拆除，以及学习一些重要的设计模式和原则。
下节课讲解微服务架构中的经典设计模式，也是面试题。
