转载

微服务架构开发和平台演进

这是刚刚结束的 AWS Summit北京站的分享，微服务，中台最近特别火，越来越多的公司在实际项目中开始思考和应用，比如今天分享的嘉宾阿迪达斯和欣和电商数字化转型；

虽然，我们每个人都在讲微服务，但我们还是回归初心，当你讲“微服务”的时候，你的脑海里浮现的是什么？你怎么驱动公司和团队采纳微服务？怎么用非技术语言让业务能听懂微服务的价值？

建议大家观看一个视频，伟大领袖如何激励行动 TED演讲：伟大的领袖如何激励行动_腾讯视频；里面提到一个非常有意思的认知“三环 ”,绝大多数人是由外而内（What=>How=>why），但伟大的公司或领导者，思考的路径通常是由内而外（why=>How=>what），团队或者客户认可的常常是你的理念/信念即“为什么”，从而愿意接受你的产品或服务；如今天猎豹移动CEO傅盛所分享的猎豹围绕工具为核心的三个阶段，从PC到移动到AI，机器与人共存的世界里，用科技让生活更美好，所以，猎豹做了不同场景的机器人，不同的场景做到辅助美好生活的方方面面的智能“工具”，一下子把猎豹、工具和美好生活关联了起来。

微服务架构开发和平台演进

再举亚马逊自己的例子，亚马逊电商的单体转型到 SOA最终走到了微服务，背景是业务全球化高速发展，单体架构的紧耦合，导致新业务新功能上线的代价和时间成本不可接受；另外，随着站点的用户访问规模不断上涨，单体架构的可用性也压榨到了极限；因此，这样的一个背景下，我们的创始人贝索斯定下了一个应用API化6条军规（具体见我DDD的内容分享）；

因此今天我们从三个维度来进一步解读微服务成功的三个方面：（1）以客户价值为核心的设计思维，Amazon的实现方法是逆向工作法（2）微服务架构方法，AWS的优良架构方法可以帮助客户，梳理领域架构，事件架构，数据架构，安全架构，大数据架构等等。（3）软件服务更看重运营，基于云服务的持续交付和运营，极大降低了企业实现微服务的技术门槛，和后续运维成本。

设计思维：从客户出发，逆向工作法

这方面我在火币分享的 DDD内容有比较详细的阐述，就不在这里赘述，唯一要提的一点是，AWS专业服务团队可以提供研发团队管理，数字化创新工作坊等各种云数字化转型咨询和实施服务。

微服务架构开发和平台演进

优良架构方法指导微服务架构演进

完整的微服务架构设计，包含利用设计思维寻找亮点，根据数据思维验证和优化，再通过技术设计来落地实现；设计思维，目前社区比较流行领域驱动设计，AWS总结的经验是逆向工作法，包括新闻稿，常见问题和图例来沟通客户场景和解决方案价值。数据思维强调，所有的用户体验和价值都是可计算的，比如用户增长中计算用户价值的RFM模型，其中Recency：最近一次购买时间、最近一次登录时间、最近一次发帖时间、最近一次投资时间、最近一次观看时间；Frequency：购买频率、浏览次数、发帖次数、评论次；Monetary：消费金额、充值金额、打赏金额、评论数、点赞数；计算这些指标从而进行客户价值分类和画像，从而制定个性化营销方案进行用户留存、转化和激活。

微服务架构开发和平台演进

从技术实现来看，单个微服务的实现，很多客户都很好的总结成了脚手架工程，但工程重要的层次和架构思路，一个比较流行的框架是六边形架构即端口适配器架构；加上领域驱动的概念的话，会有一个独立的领域核心，外围包裹应用逻辑，和暴露的接口，和服务本身上游接口的调用适配器。

微服务实现的还有一个非常大的挑战是数据架构；服务共享数据库还是独立数据库常常是技术实现中一个非常大的争议点。按照我们的 API化原则，服务之间只能通过API互相访问，不允许任何形式的直接数据层访问。

微服务架构开发和平台演进

多个微服务必然会涉及到服务间的通信问题，通常有同步和异步两种方式，协议的不断优化和演进，提供了我们很多选择，下面总结了常用的通信方式：

微服务架构开发和平台演进

服务之间通信质量受网络的影响比较大，因此我们要考虑服务失败处理的问题，通常有快速失败，流量控制，指数回退方式重试，断路器，幂等，回滚等处理方式，避免雪崩式系统整体不可用；

为了避免服务直接通信带来的紧耦合问题，服务寻址即注册发现机制，也在一直演进中，独立的注册表，客户端服务发现还是服务器端服务发现，还是利用服务网格（ServiceMesh）方式将服务治理能力下沉到基础设施平台层从而减轻微服务治理在代码实现的负担：

微服务架构开发和平台演进

微服务架构支撑用户体验的角度来看，必然存在不同层次，以Spring Cloud为例，为了实现前后端分离，很多互联网公司的实践表明，后端接入层也是由前端人员来通过Nodejs的方式隔离前后端的耦合，实现前端后端服务快速迭代，从而得到一个解耦的分层架构。越底层的服务相对越稳定，质量要求越高。

微服务架构开发和平台演进

上面提到，后台直接跟前端交互的，通常会有一层抽象层，该层通常需要聚合或编排更底层的微服务，提供前端各种定制需求。

微服务架构开发和平台演进

微服务架构导致服务数量会不断增多，整个系统健壮性和可用性受到很大挑战，所以Netflix倡导并实践了混沌工程方法，在分布式系统上进行由经验指导的受控实验，观察系统行为并发现系统弱点，以建立对系统在规模增大时因意外条件引发混乱的能力和信心。（扩展阅读可以参考资源链接更多资料）；架构都是不断演进的，那我们有没有一个checklist帮我们不断反思架构设计，给出调整建议呢？AWS Well Architected 就是这样的一个工具。

微服务架构开发和平台演进

云交付：从开源出发到云原生

微服务架构开发和平台演进

微服务架构和生态需要的复杂服务治理等非功能性需求，经过这几年的实践很多都沉淀到了底层云平台服务，客户完全可以基于这些现有的轮子进行业务创新。在微服务架构中，API接口，事件和数据是三个主要的架构因素。对于API接口，API 网关是非常实用有效的一个模式，一个好的网关服务，可以支撑服务路由，A/B测试，认证授权，限流，监控集成等常见的功能，后端更可以接入任何形式的服务运行载体，比如容器服务，虚机微服务，函数微服务，甚至第三方的接口等等。

微服务架构开发和平台演进

对于很多前后端以数据为核心交互的场景，大量的REST接口调用，带来管理的复杂性，前后端对于REST的定义耦合度比较高，为了简化和提升灵活性，社区推出了GraphQL框架，为前端提供唯一的服务入口，同时提供前端灵活的数据查询和实时事件交互机制，海外很多大型互联网公司都在生产上采用了GraphQL的实现前后端数据交互。AWS托管的AppSync服务就是GraphQL在AWS的全托管服务，详情大家可以查看我们的官网资料。

微服务架构开发和平台演进