微服务和容器化的研究心得 - 好文

1、基本概念和原理

微服务架构是一种架构模式，它提倡将单一应用程序划分成一组小的服务，服务之间互相协调和配合，为用户提供最终价值。一个大型复杂软件应用由一个或多个微服务组成。系统中的各个微服务可被独立部署，各个服务之间是松耦合的。每个服务运行在独立的进程中，服务与服务间采用轻量级的通信机制互相沟通。微服务的目的是有效的拆分应用，实现敏捷开发和部署。
微服务架构的优势：复杂度可控、独立部署、技术选型灵活、容错、扩展。

业界常用的微服务开发框架有：Dubbo、Spring boot、SpringCloud等。常用的通信机制协议有RPC、REST。

微服务落地存在的主要困难有如下几方面：

1）单体应用拆分成分布式系统后，进程间的通讯机制和故障处理措施变得更加复杂。

2）系统微服务化后，一个看似简单的功能，内部可能需要调用多个服务并操作多个数据库实现，服务调用的分布式事务问题变的非常突出。

3）微服务数量众多，其测试、部署、监控等都变得更加困难。

随着RPC框架的成熟，第一个问题已经逐渐得到解决。例如dubbo支持多种通讯协议，SpringCloud可以非常好的支持restful调用。对于第三个问题，随着docker、devops技术的发展以及公有云paas平台自动化运维工具的推出，微服务的测试、部署与运维变得越来越容易。而对于第二个问题，是最具挑战性的一个技术难题。目前阿里采用GTS。

因此，要想使用微服务带来的优势，就需要使用容器引擎（比如Docker）来实现容器化。并且还要解决分布式事务的难题。

常用容器Docker，是一个开源的应用容器引擎。Docker介于VM与应用之间，更类似于VM，但比VM更加灵活的分配资源。Docker容器通过Docker镜像来创建。容器可以将应用依赖的中间件和软件都打包进去，为基础环境的部署和运维提供了便利，能很好的支持DevOps。

2、微服务架构演进的思考

目前我们的企业级架构是SOA架构，要演进到微服务架构，首先需要从业务和应用层面对目前的组件进一步拆分成微服务。拆分的大原则是当业务不依赖或极少依赖其它服务，有独立的业务语义，为超过2个的其他服务或客户端提供数据，那么它就应该被拆分成一个独立的服务。其次，微服务提倡的理念团队间应该是inter-operate，not
integrate。inter-operate是定义好系统的边界和接口，在一个团队内全栈，让团队自治。这样，每个服务从开发、测试、运维等都是独立的，自己就有一套完整的流程，完全可以把它当成一个项目来对待，不必依赖其他服务。还有，我们需要解决分布式事务这个难题。解决方案有：基于XA协议的两阶段提交方案、TCC方案（Try、Cononfirm、Cancel）、基于消息的最终一致性方案、基于冲正的一致性方案、GTS（阿里分布式事务解决方案）。最后是选择合适的微服务开发框架、轻量级通讯协议、容器引擎以及DevOps。
上述这些要点都需要应用架构制定统一的原则和技术选型。

对于现有传统架构的系统迁移到微服务架构，可以考虑将服务分为四类。基础服务（文件服务、消息服务、短信服务、机构员工服务、客户信息服务等）、接口服务（前置类系统、ESB）、组合服务（结售汇、资管、同业等）、其他服务（客户端服务、监控服务等）。

基础服务由于最符合微服务的特点，应最先进行迁移。而组合服务，就是涉及到了具体的业务，一般放到最后再进行微服务化改造，因为这类服务最为复杂，除非涉及到大的业务逻辑变更，否则是不会轻易进行迁移的。还有考虑传统服务和微服务的配合方式，所有微服务可以通过微服务网关来对外提供统一的访问入口，所有需要和微服务架构内部服务进行通讯的请求都走统一网关。

3、同业公有云输出的相关思考

如果同业云输出项目要进行微服务化，需要考虑以下方面：

1）制定统一的微服务架构相关原则和技术选型。

2）从业务和应用层面梳理现有系统有哪些服务需要微服务化，尤其是基础服务。

3）必须有容器化、DevOps、公有云paas平台自动化运维工具的底层支撑。

4）考虑项目实施周期、技术难度以及投入产出性价比，建议采用分阶段实施策略。组合服务如果没有大的业务逻辑变更，则不进行微服务化。基础服务优先进行微服务化，可作为试点。有大业务逻辑变更的组合服务可考虑进行微服务化。

热门工具换一换