1.引子
关于微服务这个话题，事实上大家都很熟悉了，那么今天我们就不聚焦在如何使用框架上，比如说一些rpc框架的使用、再比如说spring cloud 组件的使用，毕竟官方网站资料足够丰富，或者借助搜索引擎我们也能使用起来。
今天，我主要想跟你分享中小企业中，在微服务架构体系设计上的一些思考，通过抛砖引玉的方式，一起交流学习！我设想了这么一些内容
- 什么时候，应该考虑微服务架构这个事儿
- 微服务架构，与组织架构的适配
- 中小企业微服务架构全景视角
2.案例
2.1.微服务架构时机
企业发展在什么时候，考虑微服务架构比较合适呢？这个问题的答案，它不是有钱就行，不是有人就行，它一定是有需要的时候才行。这不是句废话嘛，对吧
是个人都知道，我们做任何事情，都是因为有需要！
但是，需要两个字该如何理解呢？你比如说，我们是一家刚起步的创业公司，首要任务是要活下去，要把业务模式跑通。这个时候用什么技术并不重要，业务才是放在第一位的，因此我们说这个时候，不需要考虑微服务架构那么复杂的事情，All in one一个单体应用就ok了。
企业发展过了一段时间，我们运气好，业务模式跑的还不错。业务体量越来越大，业务复杂度越来越高，团队小伙伴越来越多。
有一天，你突然发现新增一个小小的需求，效率竟然低到让人无法忍受：开发慢、测试慢、发布慢。构建打包居然都花费了半个小时！
于是老板把你叫到办公室，问：有没有什么方法，改善一下？
你想了想说：我们是不是需要考虑微服务架构了？
是的，这个时候，就是我们需要微服务架构设计的时候了。我通过一个坐标图，给你展示关于单体应用，与微服务架构的时机，你一看应该就明白了
图解，我们发现
- 业务早期，业务体量小，业务复杂度不高，这个时候是更加适合单体应用（研发效率更高，更适合快速上线试错业务模型）
- 随着业务发展，到一定阶段，业务体量上来，业务复杂度高以后，这个时候更加适合微服务（在高复杂度业务体量下，微服务的研发效率更高）
2.2.微服务架构与组织
在需要实践微服务架构的时候，技术以外，我们还需要考虑组织架构的问题。即微服务架构实践相当于一个拆烟囱的过程，这里的烟囱有系统烟囱，有组织烟囱
当然我们拆烟囱的目的，是为了实现微服务架构收益的最大化。下面我还是通过图的形式，来呈现什么样的组织架构更加适合微服务
图解，我们发现
- 传统职能型团队，它的特点是从人的角度，按照职能划分团队，比如说产品、研发、测试、运维等。当启动一个项目，我们其实是从不同的职能部门找人，组建成一个临时的项目团队。这个时候团队成员之间的沟通协作成本其实是很高的，大家习惯不一样，风格不一样，需要一个磨合的过程。
- 跨职能型团队，它的特点是从产品（或者项目）的角度来划分团队，比如说订单团队、物流团队、支付团队等。每个团队成员都是长期、全职服务某个产品，团队成员之间的沟通协作会更加高效
2.3.中小企业微服务架构全景视角
2.3.1.分层逻辑架构设计
不管是在单体应用，还是微服务架构设计中，分层架构设计是一个通用的设计思想。这个时候，我们会考虑这么一些分层
- 接入层（用户界面对接层，提供PC、APP接入能力）
- 网关层（提供路由、流量治理、发布策略支持，简化客户端调用等能力）
- 应用服务层（聚合原子业务，提供上层应用服务能力）
- 领域服务层（通用业务下沉，提供原子业务能力）
- 应用支撑层（提供通用基础技术服务能力）
- 基础设施层（资源层，提供计算、存储、网络能力）
2.3.2.中小企业微服务架构体系
在中小企业中，我们可以参考下图的方式建设基础微服务架构体系，包含
- 应用支撑服务：网关、服务注册发现、配置中心、安全中心
- 业务集群：微服务集群
- 监控平台：指标监控、日志监控、链路监控
在这个架构体系里，我想可能会引起你思考的地方是数据总线这个组件。为什么不直接对接监控平台，而通过数据总线的方式对接呢？
我们知道，不管是指标监控，还是日志监控，我们都是可以将微服务，与监控平台直接整合对接。比如说
- 通过 Prometheus 监控指标，我们只需要在业务服务中将指标数据暴露即可
- 通过ELK监控日志，我们只需要将日志推送到LogStash即可
既然都可以直接对接，为什么还要增加数据总线组件呢？增加数据总线组件，主要是基于数据共享与传递性方面的考量。比如说我们后期还需要增加风控能力，这个时候风控系统直接从数据总线获取数据即可
最后我们来看图：
