架构师训练营第十周学习总结

一、微服务架构

什么是微服务架构？

微服务架构，我的理解就是把一个复杂的系统或者功能模块，采用按功能职责单一、数据独立、微型化可分布式运行、集群化部署的一种组织结构，并且对外采用统一的协议提供服务如（RESTFULL、RPC)。

解决什么问题呢？

一、巨无霸应用系统带来的编译、部署困难

编译问题在我的经历中到还未存有过，但是部署的问题确是一个很折腾人的事，经常因为有的别的模块配置文件中未配置导致无法启动。并且当每次一个tomcat启动要好几分钟的时候。

二、代码分支管理困难

指：复用的代码可能由好几个组在共同维护，代码合并冲突时总会发生各种各样的问题。

三、数据库连接耗尽

这个在我的经历中深有体会，不同的功能模块都连接同一个数据库，每个功能模块都有一个独立的连接池。在Struts流行的年代，try {获取连接} catch{}finally{释放连接池}的年代。要是某个同学的代码中没有在finally中释放连接池。要查这个连接池被耗尽的问题，没有几个小时是查不出来的。并且一影响，就直接把整个系统搞宕机。

四、增加新业务困难

别说增加新业务，就是你想加一个字段，有时候都是一种奢侈。因为在单体的时代，代码与代码之间，功能模块与功能模块之间的耦合度非常的高。

五、业务回滚困难

某天老板说要增加新业务，新业务和旧的业务又有千细万缕的联系，辛苦了几个月后，测试OK、经历痛苦的上线后，突然老板说这个先暂停，先回退到上一个版本。这个没有什么，但是如果在一同上线的时候或者上线前有别的功能模块又有新修改的线上问题各种各样的依赖关系。这时候的五味杂阵。



微服务一般的架构图

(网上找一个图)

接入层

接入层负责把外部的流量接入到内部平台系统中来，涉及到更多是基础设施，由运维团队进行负责。

网关层

流量接进来之后，会先经过一个网关层，网关在微服务起到举足轻重的作用，主要起到反向路由，限流熔断，安全，鉴权等等的跨横切面的功能，这个层在微服务中起到核心的层次。

业务服务层

整个业务服务按照逻辑划分为两次，分别是聚合层和基础服务层，聚合层对基础层进行聚合和裁剪，对外部提供业务能力。当然这个视每个公司不同情况而定，此层再划分两层是属于逻辑划分。

支撑服务层

支持服务包含了注册发现，集中配置，容错限流，日志聚合，监控告警，后台服务，后台服务涉及到例如MQ，Job，数据访问等。

平台服务层

这一层主要是由CICD构建起来的DevOps。例如：基于docker 、 keburnetes构建的容器，镜像的管理，容器的服务编排等。

基础设施层

基础设施层主要是由运维团队来进行维护，设计由计算，也计算资源的分配，网络，存储，监控，安全等等

带来了那些的新问题？

一、拆分服务的粒度如何去权衡。例如：会员与会员积分，这是做成一个服务？还是拆成两个服务呢？

二、增加了查找问题的深度。

三、增加了运维的成本。

四、由于数据库的独立，统计报表或者跨业务表查询，相较于以前来说变得困难了许多。

二、DDD

对于DDD来说我是很期待，网上一堆关于DDD的介绍。那个搞得我是头昏眼花的，还没有敢尝试就被吓到了。怀着很大的期待，希望李老师能给我们讲讲他们在业务中采用DDD是如何做的。

开始，我的关注点是在如何去做（李老师并没有讲如何去做，有点小失望）

后面听了李老师分析的一个案例后突然思路就打开了（认为没有讲如何去做是对的，DDD要讲的太多了，容易带入坑中）

通过学习了案例之后，我个人认为

DDD为我们开发复杂软件或者系统提供一种从战略到战术上的系统设计思想或者解决方法

案例

需求

业务需求

第一次，解决听书这个业务模块的需求



后面财务要求：所有的业务都要订单化



这下遇到的新问题了

新的任务需







问题域+目标



怎么办

1、统一认识

首先 开发团队与业务需求方，需要用统一的语言（简短的文字或者词汇）大家都能理解的，达成认识上的一致；如下图2中所示。

2、梳理出统一语言，找到真正的业务需求



3、不断的进行领域问题提取和建模，最终划分出不同的子领域及限界上下文



如下所示一个子领域分析过程







4、最后得到的领域





5、如何变化的呢?

原来的

现在

6、最近的系统逻辑就变得很清爽了

整体订单交付系统，就是一个好莱坞原则。客户端->提交产品->交付系统，业务系统按交付系统约定的接口或者格式返回相应的数据。由交付系统去处理后续的业务。再加一个新的同类业务，也变得相对的容易许多。