当然另外一个就是我们选 Spring cloud 的原因就是 Spring cloud 本身做微服务架构生态非常完善。提供的微服务开发框架是超过 35 个以上，有一系列框架对，对接不同的数据源。包括 Spring boot 也非常好用，简化了整个开发过程。但是另外一点也稍微注意一下，作为一个 Java 开发者，有些人是用框架很熟，不懂底层。尤其是新入行的一些成员可能会被 Spring boot 给迷惑住。
后面的开发企业越来越简单封装的越来越好，很多人就不懂底层原理了，需要稍微注意一下。在座的各位花时间可以抽空研究一下底层原理。Spring cloud 它是植根于Spring 平台之上，并且可以很好的和一些 Spring cloud 框架进行集成，我们可以快速的去落地我们微服务架构的一个方案。
大家在搭建微服务过程中，前面已经强调很多次，维护结构本身的坑比较多，或者叫挑战性问题比较多，架构师的职责是非常重的。之前的话，大家很容易就说自己是一个架构师。比如我会设计一个三层，或者设计一个四层，打个安全卡的集群，我就认为我是个架构师，在一个公司里面就可以混得很好。
但是咱们讲一个问题，你现在再吹自己是架构师，微服架构师的话，在这里面就有点麻烦了。前面已经讨论过很多次了，很多公司都有这种就声称自己技术很牛逼，或者声称自己是技术非常厉害的人，但是你让他写代码或者让他自己去搭一套框架，他基本上搭不出来。有些只是会画大饼，这种其实是比较遭人反感。
微服架构师一般人不敢随便说，很多原因就是因为他知识点太多了，容易说错，你说你是微服架构，我就问其中那个框架你是怎么用的，你解释不出来，你这就丢人了，所以现在的话大家也可以看到在技术圈里面装逼的话是不轻易装大数据架构师，也不轻易装微服务架构师，因为这两个体系都足够复杂，这也是比较逗的一个现象，当然你说你是一个普通的 Java 架构师，这就不好衡量。你是一个 3 层架构师，还是一个 4 层架构师，那就不好说了，所以如果你说你是微服架构师的话，我就问一下其中的某一个点
你是怎么做的，怎么解决这个问题，那就不一样。衡量的难度一下尺度就上来了，我们说是这对架构师来说能力要求是上了几个台阶，而不是一个台阶。微服务架构里面，拆分以后有许多的问题，列入应用、服务注册发现等这种单点问题。
在昨天我们装的工具基础上，开始搭建微服务架构，我们先来以注册中心为例，大家先把注册中心给搭建起来，在讲为什么选十分架构的时候，也把理由充分给电压进行了一些讲解，主要还是为了后面的学习。另外就是大家的以后在汇报微服务架构的技术选型是不是可以和领导讲得比较全面透彻，这也是给大家做了这样一个总结性的第二阶段的那一刻。
咱们下节课来讲，数字中心的落地和实践由大家去写代码，我们希望大家是属于能够懂理论，又能够进行时间架构设计落地的这样的一个名副其实的架构师。
