什么时候开始微服务架构
几乎所有成功的微服务架构都是从一个巨大的单体架构开始的，并且都是由于单体架构太大而被拆分为微服务架构。
在所一开始就构建微服务架构的故事中，往往都有人遇到了巨大的麻烦。
流控设计
限流算法。限流也就是调节数据流的平均速率，通过限制速率保护自己，常见的算法有：
固定窗口算法（fixed window）。
脑裂问题
一种是采用投票机制（Paxos 算法）。
一种是采用租约机制——Lease，租约机制的核心就是在一定时间内将权力下放。
依赖，显示声明依赖。
配置：环境中存储配置。
后端服务：把后端服务当作附加资源。后端服务是指程序运行所需要的通过网络调用的各种服务，如数据库（MySQL、CouchDB）、消息/队列系统（RabbitMQ、Beanstalkd）、SMTP 邮件发送服务（Postfix），以及缓存系统（Memcached）。
团队规模导致的问题
缺乏信任。由于人数众多，难于管理，只能通过制度、流程、规范、绩效约束。
没有责任感。高层管理者忙着开各种决策会议。
全托管的计算服务，客户只需要编写代码构建应用，无需关注同质化的、负担繁重的基础设施开发、运维、安全、高可用等工作。
亚洲、中东和非洲地区的开发人员采用容器和云原生技术的速度较慢。中国的各大公司在向云的迁移方面一直滞后，并且云原生技术的使用也呈现同样的趋势。随着阿里巴巴的 CaaS 获得市场的青睐，相信将来东亚地区会涌现更多云原生开发人员。
根据调研机构IDC公司最近发布的一份《全球人工智能支出指南》，预计全球人工智能预算将在未来四年翻一番，到2024年将达到1100亿美元。
世上没有免费的午餐，微服务技术让 IT 系统变得更敏捷、更健壮、更高性能的同时，也带来了架构复杂度的提升。对于开发者而言，要想更好的驾驭微服务架构，需要解决持续集成、服务发现、应用通信、配置管理、流量防护等一系列难题。
服务版本和灰度发布
在函数计算里面，应用有版本的概念，版本是一个不可变实体，因此杜绝了版本因为非预期的修改造成线上应用受损，阿里云通过服务版本和灰度发布避免了这样的问题，客户端访问应用通过别名来访问。
