第十周学习总结

微服务关键点：服务本身的设计、治理、运维；

单体巨无霸应用系统带来的问题

• 编译、部署困难

• 工作没有成就感

• 代码分支管理困难

• 数据库连接耗尽

• 背负历史包袱，新增业务困难

解决方案就是拆分，将模块独立部署，降低系统耦合性

纵向拆分：将一个大应用拆分为多个小应用，如果新增业务较为独立，那么直接将其设计独立为一个独立的WEB应用系统

横向拆分：将复用的业务拆分出来，独立部署为微服务，新增业务只需要低啊用这些微服务既可以快速搭建一个应用系统



互联网

简单、高效以及易于使用



微服务必要条件：

1，负载均衡

2，失效转移

3，高效的远程通信

4，业务服务无感知

5，版本管理；



业务没搞清楚后，再判断是否要上微服务



命令与查询职责隔离(CQRS)



事件溯源

• 审计与复合

• 分布式事务



断路器

类似于降级策略



上游调用者超时要于下游超时时间之和



最重要的是需求

目标、价值、原则、最佳实践、合适的工具



先要知道自己想要什么，接着价值



多关注业务，技术是为业务服务的



业务逻辑无关的一些功能可以在网关层来实现

参数校验、限流控制，接口调用。pipline【责任链】



开发平台网关



开放授权协议



贫血模型和充血模型



Ddd 是充血模型实现的一种工具化的补充



个人觉得，我们现实世界中的领域有那些，他们之间的关系、职责以及逻辑是什么样子的，根据这些领域进行分析，然后设计出来我们的系统。根据我们现实的业务，进行设计，而不是根据界面进行设计。

架构师一直要考虑的问题：怎么样开发或者设计这个软件。

限界上下文：依赖关系。

聚合是微服务的最小单位。



ddd分层：接口层，应用层（组合一些事物），领域层（核心业务逻辑代码）



软件组件设计原则



高内聚

版本控制

共同封闭原则，当变更发生时，同时需要功能模块的放在一起。



组件耦合原则

无循环依赖原则：不要出现环

稳定依赖原则：较少变更的依赖是稳定的。所以要依赖变更较少的依赖。

稳定抽象原则：稳定的组件是抽象，具体一般是不稳定的。依赖抽象，不依赖实现。



组件的便捷与依赖关系，不仅仅是技术问题

康威定律，组织架构决定了系统架构。



系统重构是不可避免的



业务模块和系统边界的重构，而仅仅只是从代码或者工程架构上来重构的化，意义不是特别大。需要对顶层业务架构需要重构。





不同场景中，相同泳道中的活动可以划分到一个边界【业务边界，限界上下文边界，微服务边界】之内。



重构背景与整体规划



业务架构和服务边界不合理