目录
单体架构
功能集中，代码和数据中心化，一个发布包，整个程序运行在一个进程应用中。对于开发人员来说实现简单，对于维护人员来说维护难度随功能数量增长
微服务基础概念
所谓微服务是一种架构模式，相对应的是单体架构，规避掉了单体架构中的弊端。具体形式是将业务拆分为独立单元，每个单元有单独的宿主或者说运行在不同的进程之中，每个单元对应不同的Database(理想情况，采用分布式事物，更多的时候是不拆分Database)，彼此之间以restful Api进行资源共享，最后共同组成API gateway来为客户端提供数据。
微服务的基础设备
敏捷开发，持续交付与集成，Devops，容器化/虚拟化
微服务的关注点(技术点)
配置中心(Config Mnagement)，用软件管理配置开关达到统一性
去中心化服务(Service Discovery & LoadBlance)，把服务注册到gateway当服务down掉了，直接重新注册即可，摆脱了传统方式(需要通知客户更换了服务器地址等等)
容错(Resilience & Fault Tolerance)，相比于传统方式不确定因素或者说会产生的问题要更多，不过借助于Docker可以快速修复与快速发布
Api管理(Api Management)
Service Security
日志中心(Centralized Logging), 通过工具管理每个进程服务的log，实现统一管理
Centralized Metrics
分布式跟踪链(Distributed Tracing)
Scheduling & Deployment
弹性扩容(Auto Scaling & Self Healing)， 根据流量/并发量实现对Service实例的热插拔
微服务的特点
服务作为组件
围绕业务组织团队
关注产品而非项目
业务数据独立
基础设施自动化
架构渐变
微服务的挑战/难点
分布式系统复杂度
性能开销，采用分布式缓存/内存数据库来规避因为主要的性能问题就是在于操作DB
高可靠性
数据同步/一致性
运维保障
开发调试，单元测试必须得有
错误蔓延，出现错误直接冻结服务实例，避免出现雪崩情况(调用的/相关的服务都会报错)
整体检测
版本依赖
服务测试
依赖管理
自动部署
微服务不适用场景
事物一致性高
高性能
业务稳定
微服务技术栈
服务注册、发现: eureka
配置管理: 携程Apollo , spring config , spring security
集群容错: hystrix
API网关: zuul(Spring Cloud Gateway)
服务负载: feign+ribbon
api文档输出: swagger2
代码简化: lombok
消息队列: rabbitmq
分布式锁: redis
链路跟踪: spring cloud sletuh ->zipkin
安全认证: oauth2/JWT(通过JWT轻量级的实现)
服务监控: spring-boot-admin
Python集成: sidecar
.net相关技术栈: https://steeltoe.io/
服务注册中心
其实就是一个serve(Eureka)，可以理解为一个存储键值对的DB，key就是服务名，value是具体的服务地址，当一个请求访问服务的时候是访问的这个服务中心，服务中心查找对应的服务地址，然后转发到具体server。服务与服务中心之间需要心跳包定期检查服务是否依然有效。服务中心要保证稳定，3台VM起步。
服务配置中心
也是一个server用来管理配置文件，实现乐加载(更新即生效，无需重启服务)
网关
为调用者提供统一入口，对于高并发的时候需要限流，降级，也可以做日志记录统计，请求跟踪监控，gateway安全
熔断
熔断机制应该存在于具体的service中，用来防止雪崩(A访问B B访问C，如果C挂了/长时间没有响应，如果这时候有大量A的请求访问B，那么B必然会挂)的问题，它的作用类似于生活中的保险丝，当高电压来的时候烧掉自己防止家电损坏。熔断机制主要的作用是当C挂掉的时候，返回给B一个友好的提示，而不是大量的错误信息，然后定期去检查C是否已经可以被访问。
Spring Cloud
微服务组件提供方案 https://springcloud.cc ，用来做私有云
微服务分割标准
子系统级
模块级，用户，商品，交易等
功能级
1011
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
