微服务架构入门，一些具有代表性的问题
看了一下，觉得这些问题比较有代表性，很多准备开始做微服务架构的企业或个人都有类似的疑问，因此针对这些问题写点东西，希望对一些微服务入门者有所帮助。
（1）如何将当前的产品拆解为微服务（组件），每个微服务应包括哪些元素？
要把单体式应用拆分成微服务组件，并没有一个具像的标准说这个组件应该包括哪些元素。而是需要从业务的角度去分析：某一些功能是否逻辑相对独立、可复用性高、使用频度高等等，根据这些因素判断是否该拆分出来作为一个微服务组件。
微服务设计强调服务的独立性：不同微服务使用不同的数据，与外部交互通过消息或API而不是耦合的依赖关系;此外，微服务组件的设计需要把握“微”的度，所以不宜在基础的功能上做过多的堆叠，否则每个微服务组件可能又变成了大的单体应用。
具体来说，微服务设计需要可从以下几个方面着手：
- 实现前后端分离，可把代码分为前端、服务层、底层代码；
- 根据业务逻辑及技术层面的系统架构综合考虑，抽取模块成服务;
- 打造服务间的轻量通信基础组件及协议，例如REST或消息队列；
- 此外设计时需要注意的很重要的一点是，微服务必须要支持的外部化配置，这种配包括任何占位符信息到数据库配置等等，在初始规划和构建应用原型时，这是必须要考虑的架构内容。
（2）如何搭建合理的微服务总线和通信机制？
这个问题提到的所谓的微服务总线实际上主要包括两方面的功能：服务发现和服务调用。
例如阿里开源的Dubbo框架就是一种微服务框架，它借助Zookeeper等多种注册中心实现对Provider服务的注册，并且提供服务发现功能。
Dubbo支持Hessian、WebService、Thrift等方式的RPC远程服务调用，此外当当扩展的dubbox还支持REST API的服务调用方式。
事实上更地道的微服务架构会采用基于异步通信的调用。在异步通信中，各服务间彼此依赖，但不会因相互等待结果而导致响应速度缓慢。因此，如果一项服务发生故障，其不会影响到其它服务，瓶颈与单点故障问题也将不复存在。
（3）如何保障负载均衡和微服务系统的整体可靠性？
参考Dubbo提供的ConfigServer的原理，就可知道如何保证微服务系统的负载均衡和整体的可靠性问题了。如果你的系统是Java应用，就可以使用现成的Dubbo，当然你也可以支持根据这个基本原理写自己的微服务支持框架。
Dubbo的配置中心和每个Server/Client之间会作一个实时的心跳检测，收集并更新每个Server提供的服务的信息，每个Client的信息。
每个Server启动时，主动与ConfigServer建立连接，并将自己的IP，提供的服务名称，端口等信息直接发送给ConfigServer，ConfigServer会更新服务列表。
Client在使用服务的时候根据服务名称去ConfigServer中获取服务提供者信息，后面就可以直接调用服务了。当有多个服务提供者的时候，Client根据一定的规则来进行负载均衡，如轮询，随机，按权重等。一旦Client使用的服务它对应的服务提供者有变化，ConfigServer就会把新的服务提供者列表推送给Client，Client重新建立连接。
（4）如何管理服务组件的版本，实现快速部署和无缝升级？
微服务架构下的应用由若干个微服务组件组成，与单体式应用相比其服务组件的版本管理及部署、升级都会变得复杂了，如果全靠手工去做，必然效率底下。
一套完善的开发管理规范，包括开发设计规范、分支管理规范、持续集成规范，再利用Docker容器的天然的特性：“版本控制、可移植性、隔离性”就可以实现组件的版本管理。实质上基于在支持DevOps完整流程的容器云平台，即可实现整个开发过程及交付中的持续集成、快速部署、灰度发布及无缝升级。
（5）如何搭建配套的服务控制台和管理系统？
在容器云平台上搭建你的开发、测试及运行环境可实现容器化的持续集成持续部署，即以容器的形式发布应用。平台可以提供容器服务的监控及管理的全套功能，无需自己搭建服务控制台和管理系统。
相关文章