微服架构转型的三大挑战及应对之策.PDF

微服务架构转型的三大挑战及应对之策 王天青 首席架构师， DaoCloud云原生转型实验室 About Me • 南京大学计算机科学与技术系硕士。 • 资深Java程序员，2003年开始从事J2EE开发，从软件开发做到架构设计。 • 08年加入EMC中国研究院，最高担任云平台主任研究员，长期从事云计算 创新技术解决方案设计和实现。 • 2015年9月加入麻袋理财，任首席架构师 • 2016年12月加入DaoCloud ，任首席架构师，负责云原生应用转型实验室 • 在工作期间，分别在中国和美国提交了20+专利申请，其中7项专利被美国 专利局正式授权。 为什么要用微服务架构？ 移动互联网时代的挑战 我要支持100万客户！！！ 又快又好 公司IT投入怎么比业务发展快？？？ 为什么要用微服务架构 ？ 独角兽的成功秘诀 • Speed of innovation （天下武功，唯快不破） • Always-available services （随时、随地可用） • Web scale （从0到1 ，快速扩展） • Mobile-centric user experiences （移动为王） 软件架构比较 单体 vs. SOA vs. 微服务架构 优势 劣势 • 不够灵活：任何细修改需要将整个应用重新构建/部署，这降低了团队 • 人所众知：传统工具、应用和脚本都是这种结构 的灵活性和功能交付频率 • IDE友好：Eclipse、IntelliJ等开发工具多 • 妨碍持续交付：单体应用比较大时，构建时间比较长，不利于频繁部 单 • 便于共享：单个归档文件包含所有功能，便于共享 署，阻碍持续交付。 体 • 易于测试：单体应用部署后，服务或特性即可展现，没有额外的依 • 受技术栈限制：必须使用同一语言/工具、存储及消息，无法根据具体 赖，测试可以立刻开始 的场景做出其它选择 • 容易部署：只需将单个归档文件复制到单个目录下 • 技术债务：“不坏不修（Not broken，don’t fix ）”， 系统设计/代码 难以修改，偶合性高。 • 服务重用性：通过编排你基本服务以用于不同的场景 • 易维护性：单个服务的规模变小，维护相对容易 • 过分使用ESB：使得系统集成过于复杂 • 高可靠性：使用消息机制及异步机制，提高了可靠性 • 使用基于SOAP协议的WS ：使得通信的额外开销很大 SOA • 高扩展和可用性：分布式系统的特性 • 使用形式化的方式管理：增加了服务管理的复杂度 • 软件质量提升：单个服务的复杂度降低 • 需要使用可靠的ESB：初始投资比较高 • 平台无关：可以集成不同的系统 • 提升效率：服务重用、降低复杂性，提升了开发效率 • 简单：单个服务简单，只关注于一个业务功能。 微 • 团队独立性：每个微服务可以由不同的团队独立开发。 • 运维成本过高 • 分布式系统的复杂性 服 • 松耦合：微服务是松散耦合的。 • 异步，消息与并行方式使得系统的开发门槛增加 务 • 平台无关