说到微服务，大家很容易会想到亚马逊的OSS、Spring Cloud或者Service Comb、Service Mesh等等。其中，Spring Cloud是大家比较熟悉的一个微服务开发框架，今天分享的主题也是基于Spring Cloud的微服务设计和开发方面的内容。
相信这方面大家都应该有更多的了解，或者正在做着微服务的相关开发，所以这里我并不讲解Spring Cloud的基础知识。今天我要分享的是——怎么通过Spring Cloud和Docker等开源工具来更好地进行微服务的设计和开发。
微服务架构的设计理念和方法，可以说已经帮我们解耦了大而重的项目，帮我们解决了规模化开发的问题，实现了独立设计，减少了系统的依赖性，实现了故障隔离，实现了快速迭代等等一些分布式开发的问题。并且使用Spring Cloud这套工具组件来进行微服务的开发，也是非常容易上手的，但要做得更好，还是必须要下点功夫。
那么，怎么才能更好地使用Spring Cloud这套工具组件来进行微服务的设计和开发呢？下面我通过几个重点来加以说明，希望能通过这几点说明达到举一反三的效果。
1、使用轻量化的设计原则来创建微服务
轻量化的设计原则强调，一个用简单的方法能够实现的事情绝不使用复杂的方法去实现。当我们面对一个系统平台开始进行微服务设计时，就将面临微服务怎么划分的问题。这个时候，轻量化的设计原则就是划分微服务的标准，如果划分出来的微服务对于整个系统来说条理清楚，逻辑清晰，那么它是符合轻量化的设计原则的；相反，如果划分出来的微服务变得更加复杂了，那就是违背了轻量化的设计原则。
比如对于一个电商平台来说，我们可以按照业务功能将微服务分为类目、库存、订单、物流、评价、支付等服务，然后可以在这些基础服务的基础上创建面向用户的商城和管理后台等服务。这种微服务的创建方法就是正确的。
但是，如果这里有人将类目和库存等服务又进行拉伸，给它增加一个前置或后置什么的服务，就会变得很复杂，所以就是不合理的。
有人说，一个好的设计是要学会怎么使用减法，而一个更好的设计是在使用除法。那么，我们可以说，微服务正是使用轻量化的方法来使用除法设计。
2、通过扁平化的管理提高每个微服务的性能
微服务使用扁平化治理，给每个微服务的设计和开发，提供了最大的灵活性和发展空间，这表现在：
一方面，每个微服务可以使用独立的数据库；
另一方面，每个服务也可以使用独特的技术进行开发。
这种独立性相当于给每个微服务赋予了巨大的潜能和无限的可持续发展的空间。这样，我们不但可以对不同的微服务选择不同的数据库，还可以针对各种数据库实现各种优化的策略。
例如在电商平台中，对于类目、库存、订单等服务我们可以使用MySQL，而对于评价服务，由于其只有写入和查询的操作，为了提供性能，我们可以选择NoSQL数据库。
对于各个微服务的开发，我们可以使用多线程技术、函数式编程等技术来提高程序的并发性能，例如使用completablefuture就是一种函数式调用的、非阻塞式的多线程调用方法，它可以在服务的多重调用和多层次调用中，充分提高调用的性能。这跟Spring Boot 2.0中的反应式编程是一样的道理。
另外，因为扁平化的治理环境，这主要包含在Spring Cloud工具套件的Eureka、Zull、Ribbon等工具组件中，它们给每个微服务的部署提供了非常灵活的空间，这样，我们通过多实例的发布，就可以很轻易地提高每个微服务的高可用和高并发的处理能力。
3、用自动化设施来提高整个团队的应变能力
微服务本身轻巧灵活的特点最适合使用Docker来发布，使用Docker和Jenkins，可以很好地实现自动化的构建流程。使用微服务之后，服务将会比较多，使用自动化构建工具来实现CI/CD，即持续集成和持续交付的流程，就显得格外重要。
例如，我们过去的服务更新和部署，都要守在凌晨的时候进行，这对产品设计、程序开发、测试和运维等工作岗位而言都是相当艰辛的。使用自动化部署和相关管理措施之后，我们将可以在任何时刻实现对微服务的零宕机部署。所以，自动化的实施，也将提高产品更新对需求变更的应变能力，始终让我们的产品走在时代的前列。
自动化管理的核心工具是Docker和Jenkins：
Docker不但可以方便地为每个微服务创建镜像，也可以为微服务的运行提供运转轻灵的容器；
Jenkins通过创建工作任务，可以创建一个包含自动测试和自动部署等子任务的工作流程。
在这个流程中，我们可以通过GitLab的webhook来实现代码变更通知，然后通过Maven进行程序打包，通过docker-compose进行服务部署等等各种操作。只要我们在各个子任务中进行合理地配置，最后，就可以根据代码提交做为应用发布的触发动作，实现整个自动化集成和持续交付的流程。
Q1：现在构建微服务的技术栈有哪些？
A1：Spring Cloud和Spring Boot是比较好的，另外Service Comb以及Service Mesh也可以参考。
Q2：微服务的划分一般是按大的业务功能来划分的吧？那如果各个微服务中有通用的功能，比如打印、导出等，还是分别调用自己的？
A2：是的。如果有的业务有通用的功能，也可以做成一个单独的服务。
Q3：拆分微服务后，给运维增加了很大负担，也给整体调用跟踪带来挑战，如何解决？
A3：调用跟踪可以使用zipkin链路跟踪服务。运维的话我刚才说过了，就是使用Docker和Jenkins等工具来实现自动化部署。
Q4：问不同主机的Docker 网络是用什么来实现？
A4：Docker如果单独发布的话，网络比较好处理。如果使用Docker Swarm等工具的话，必须使用其特有的网络来管理，这可以参考相关工具说明。
Q5：微服务架构本身都具有负载均衡、高可用等，且分布式部署，那我们在实际项目中就不用考虑使用传统的负载均衡设备或软件，不用搭建应用级别的高可用了吧？
A5：是的。但是有时我们会用到网关来提供更高一层的微服务访问控制，这时候网关这一层还是可以使用诸如NG等来做负载均衡的。
Q6：拆成一个微服务，尺度有没有参考？多小才适合拆？
A6：这个其实没有具体的标准，只要符合轻量化的原则就可以。一般按业务来分，只要是功能单一那么就是合理的。
Q7：Service Mesh 和 Spring Cloud 各自适合的场景是？怎么取舍？
A7：Service Mesh是从基础设施层提供微服务，Spring Cloud是从应用层来使用微服务，开始使用微服务最好还是从Spring Cloud开始吧。
https://m.qlchat.com/topic/details?topicId=2000001931438817
230721
1、导入Mongo Monitor监控工具表结构（mongo_monitor…
上面提到： 在问题描述的架构图中我们可以看到，Click…
PMM不香吗？
如今看都很棒