关于微服务架构，你不得不知道的事

Posted 2020-08-10

　　现如今随着新一代IT技术的发展，业务需求变的日益复杂，企业对于IT的敏捷性有了更高的要求，需要快速部署、开发、上线、迭代。传统的IT架构面临巨大挑战，往往系统还未搭建好需求就已改变。所以，以云计算、大数据、移动互联网和物联网等新一代IT技术作为技术支撑，微服务架构模式应运而出，为敏捷部署以及复杂企业应用实施提供巨大的帮助。

　　微服务架构不是凭空而来，互联网的连接正在变革一个个的应用场景，（2C端）比如说拼车、滴滴打车，出门前就可以把车叫好，在北京还有回家吃饭的app，在周边的人做了饭就给你送过来，类似于这样的应用的连接，移动app连接一个个人，把碎片化的需求对接起来改变一个个应用场景。（2B端）还有物联网的场景也在改变物联的场景，像智能制造，很多领域由于物的连接，实时数据的产生、实时分析，这些应用场景会带来我们的传统IT系统，都将面临着重构，因为这种场景下面需随时交付、随时大量用户的并发、随时大量数据的采集，特别是物联网大量的交互，传统的IT架构是无法支撑这样的大量的并发和大量数据的存储处理，传统的应用系统也都将面临重构；这个时候云基础设施和微服务架构为应用的快速创建和快速迭代提供了条件：底层有一个云基础设施，包括IaaS、PaaS，在这样的基础上快速构建微服务，从上到下都是弹性可扩展的。随着交互量自动就支持它，这样的话基于微服务架构重构应用系统来支持业务的转型和快速创新，这是我们各行业面临的一个挑战与机会。

　　但我们有一个不得不面临的问题：如何处理遗留系统？国际上已经形成了一些经验，两条腿走路：

　　第一，卡住遗留系统。给遗留系统像微服务一样创建API协议，在旧系统边缘逐渐创建一个新系统，让它慢慢生长几年，直到旧系统被卡死。

　　第二，新功能用微服务。所有的新功能用微服务去做，逐渐在遗留系统周围创建一个原生云系统。

　　解决了遗留系统后，我们如何做好微服务呢？

　　首先，从文化上，我们要从传统烟囱式的开发走向持续的开发和交付，一边开发一边测一边交付，从大项目交付走向持续交付。过去都是做大项目，一做就是半年一年，现在是持续交付，没有完成时，永远都是测试版；另外还要从中心化治理到去中心化自治。

　　其次，从组织上，我们要构建两个非常重要的团队：云基础设施团队和微服务架构业务能力团队。每个服务都是处理一块业务，过去都是做项目，现在不再是做一个个大项目，而是做一个个微服务，需要业务能力的团队，它就是业务能力的开发。从项目团队到业务能力团队，打造平台运营团队，给业务运营团队提供自服务的、敏捷的基础设施平台。

　　再次，从技术上，要拆分。应用要拆分，数据也要拆分，做容器镜像，通过容器的方式快速的部署，从ESB总线编排到事件驱动。

　　最后，从总体上，互联网技术核心就是分布式：我们一直在拆，不断的拆，最早从把数据从应用里面拆出来，数据又拆成交易数据、缓存数据，应用也是拆成前端、后端。根据并发量，应用也不断的拆成微服务。所以整个来讲，技术的发展就是不断的拆分，使它变的弹性、可扩展，变成可以独立的更新。另外一个重要就是API Gateway，API的网关：今后是个API的经济，我们的内部API、外部API怎么使用它，各种各样的SaaS服务就是通过API使用它。未来的应用的使用就像Appstore的模式，很多的API就是一个个的商品，我们能调用它，很多API可以组合成一个商品、一个APP，也有可能某一个API直接提供一种服务，也有可能是微服务组合成一个服务。

　　怎么做好这件事情？培养和组建微服务架构开发能力的团队，无疑是实现互联网转型的关键因素。中国新一代IT产业推进联盟正致力于培养新一代IT人才，特别是微服务架构开发人才，通过示范工程，从应用到技术的整合，引导我们朝一个新的模式转型。