微服务基本概念
- 专注做好一件事。一方面服务的大小是相对的，而且服务越小，服务数量越多，管理起来就越复杂，这也需要利弊权衡。
- 自治性。即服务通过暴露API，服务间通过API通信，解耦合。
微服务的好处
微服务的好处主要是针对传统的大型复杂服务而言
- 技术异构性。每个服务可以选用自己的技术，尝试自己需要的，或者新的技术，而不影响其他服务
- 弹性。服务之间有边界，即一个服务有问题不会影响其他功能，或者其他服务负责的功能。
- 扩展。如过一个服务有性能问题需要扩展，那么不需要同时扩展其他服务。
- 简化部署。一个服务的代码修改，不需要部署其他服务。
- 与组织结构相匹配。各个团队可以负责自己的N个服务，而不用管其他团队的服务。
- 可组合性。因为通过API进行服务通信，所以其他模块都可通过API对接某个服务
- 问题：没有银弹。多服务管理复杂，部署、测试、监控等方面都需要额外的开销。
如何建模微服务
主要讲了什么时候划分出微服务，总结是，先内部分模块解决，再等界限清晰，最后划分微服务
模块和服务，不要过早使用微服务：微服务是目标做到、而且容易做到 高内聚低耦合的，当我们通过逻辑或者功能来划分时，比如一个进程内，可以优先考虑多模块划分，这也是一种减少耦合的方式。而这些模块的划分，也是以后划分微服务的最好备选。
所以一个新系统，如果界限不是特别清晰，可以先考虑做模块划分，因为服务之间的边界搞错了后面的修复代价很大。所以最好等成熟后，界限稳定后，再划分新的微服务。
集成
集成是微服务相关技术中最重要的一个。也能很好的保持微服务自治性。
这些技术能够提供的好处显而易见，服务隐藏了内部实现细节、内部的技术细节，对外只暴露API，服务的内部修改也不影响外部的访问。
- 避免使用共享数据库
服务之间通过API相互访问，如果通过共享数据库，就会把数据库全都暴露出来，所有细节外部都能看到，而通过API的合理约束，数据库的很多实现就会被屏蔽，内聚性能得到很好的保证。
- HTTP和RPC
HTTP请求一般都通过JSON，这样请求的封装开销是个问题，明文传输更易于调试，而且现在流行程度也决定了它的适用性
RPC延时更低，很多都是二进制协议更高效，
- 异步协作
微服务的时间发布和消费需要考虑异步，消息队列(Rabbit MQ等)是常见的选择，优势是 可订阅可消费，消息也有状态，不会重复消费，降低耦合，伸缩性好，劣势是使用有复杂度。不过已经是最优解
- 服务即状态机
合理的服务要有自己的状态，比如服务有自己的配置db，每次操作服务就会更新db的值(状态)，避免服务成为贫血服务(即只做CRUD的简单服务)
- 版本管理
经常遇见的一个情况，是新用户有新需求，那么可以做的选择是
- 同一个服务上做新的接口给新用户，老的接口给老用户，最后实现老用户迁移，最终停止使用老接口
- 同时使用多个版本的服务，每个服务独立对外提供接口
大部分情况下，还是第一种方案最适合，第二种方案过重。短时间使用两个服务也许是合理的，但是这样多个接口存在的时间越长，就越应该考虑第一种方案
规模化微服务
主要是描述如何正确的处理服务的bugs
- 故障无处不在， 故障是无所不在的，拥抱故障，很多设计从这个角度出发，就可以避免做一些额外的防止故障发生的设计，而是多考虑故障后怎么处理才是最合理
- 功能降级，即能够动态的对出问题的功能进行屏蔽，不影响其他功能的使用。比如购物车出问题，就替换成文字提醒、电话号码、人工介入
- 多做失败和混乱的处理，所谓捣蛋的猴子军团，让他们在任意时候对系统的任意系统捣蛋，你是否可以做到快速反应，比如shut down某台服务器，增加网络延时，
- 设置超时
- 断路器，如果下游系统出问题，一直返回失败，那么断路器的作用就是不再往有问题的服务、下游 发送请求，直接返回，并对下游做心跳检查直到恢复正常
- 舱壁，即把自己从故障中分离出来的方法，比如为每个下游服务设计单独的连接池，这样一个连接池被用尽，其他服务不影响。不过这样增加了复杂度，浪费了资源，要根据自己业务场景来考虑
- 幂等，多次操作产生同一个效果，即为幂等，这需要根据业务模型来决定是否实现。HTTP的GET和PUT在规范里是定义为幂等的，但是还是依赖于你自己的实现。-- 这个如何在业务代码中实现呢？
来源：https://www.cnblogs.com/jiangz222/p/10434526.html