总体技术架构图一共分了6层
接入层
也可以叫负载均衡层，把外部的流量引入到系统中来。一般负载均衡软件有nginx，lvs，还有各大云服务厂商自己的负载均衡服务。
网关层
内部接口的一些认证、安全、鉴权、过滤、限流等服务，一般处于这一层。这一层把内部的服务接口做一层安全隔离，保护内部服务，同时也可以实现一些其他需求，比如前面讲的鉴权、黑名单过滤等等需求。所以这一层在微服务架构中是很重要的一层。
业务服务层
基础服务和聚合服务
基础服务：根据业务特点又可以分为核心基础服务、公共服务、中间层服务等。
聚合服务：把下面细粒度的基础服务再进一步封装、关联，组合成新的服务，供上层调用。这一层可以实现多变的需求。
上面的这种划分是根据逻辑来划分，各个公司可以根据自己实际的业务需求来进行划分。
支撑服务层
微服务能够成功实施落地，这一层与下一层CI/CD的配套设施是非常重要。微服务不是把上面的业务服务写完就完事了，在服务治理的过程中需要很多配套设置支持。
这一层包括注册服务中心，配置中心，监控报警服务，日志聚合服务，调用链监控几大服务，后台服务涉及的服务有消息队列，定时任务，数据访问等内容。
平台服务层
这一层是实施业务弹性治理的关键。集群的资源调度：扩展和减少。业务量上来时，可以弹性增加资源。
在微服务建设过程中，可能会遇到一些突发事件。比如微博明星热点事件，会导致访问量暴增，这就需要能实时增加服务资源应对这种突发情况，热点过后，又要减少资源。
镜像管理和发布系统配合使用可以应对出现的这种情况。所以很多团队后面会引入docker+k8s，容器，镜像管理，容器服务编排。此外，基于CI/CD的DevOps也是构建在这一层能力。
基础设施层
这个是最底层的基础设施，网络，存储，硬盘，IDC的部分。
laas 这个概念就是针对这一层。
上面的这个架构图，还可以有其他的表现形式，比如把支撑系统服务画在2侧面，只要能正确表达出架构思想。