阿里云王牌架构师一问开发者：我须要一个高并发的架构，个人系统要改形成微服务吗

摘要： 最近你们都在谈微服务，随着愈来愈多的在线业务须要提供更大并发的scale-up 和 scale out能力，微服务确实提供了比较好分布式服务的解决方案。

 

阿里云高级解决方案架构师 杨旭

世界最大混合云的总架构师，4年前，开始做为双11阿里云技术负责人，负责搭建全球最大的混合云结构，把 “双11”的电商业务和技术场景在阿里云上实现，并保障这个混合云在双11当天可以知足全球客户的购物需求。

正文：

最近你们都在谈微服务，随着愈来愈多的在线业务须要提供更大并发的scale-up 和 scale out能力，微服务确实提供了比较好分布式服务的解决方案。

微服务并不陌生，知道SOA其实也就很容易理解微服务，能够把微服务当作去除了ESB的SOA。ESB是SOA企业服务架构中的总线，而微服务是去中心化的分布式软件架构，我的认为最大的设计区别在于设计初衷：

1. SOA是为了最大化的实现复杂系统代码的可复用性
2. 而微服务是为了最大限度的解耦，不一样业务系统甚至能够是不一样语言之间的通讯

没有最优的架构，只有最合适的架构，一切系统设计原则都要以解决业务问题为最终目标，脱离实际业务的技术情怀架构每每会给系统带入大坑。全部问题的前提要搞清楚咱们今天面临的业务量有多大，增加走势是什么样，并且解决高并发的过程，必定是一个按部就班逐步的过程。
网上的一张图很经典，总结的很是好：

整个系统进化分为三个阶段：

x轴，水平扩展阶段，经过负载均衡服务器不断的横向扩充应用服务器，水平扩展最重要的问题是须要注意不用服务器之间的如何保持session和会话同步，不能让用户在不通服务器之间切换时有感知应用扩展后天然遇到的问题就是DB的瓶颈：链接数，iops等。

z轴，就是对数据库的拆分，难度上了一个台阶，Sharding的基本思想就要把一个数据库如何进行切分，能够分为水平切分和垂直切分，水平切分相对简单，一主多从，多主均可以，根据业务的须要，多主切分设计时须要注意主键的关系，解决多写在进行数据同步时候的冲突问题，垂直拆分更加复杂，通常都会涉及到架构逻辑的改造，须要引入中间件，来进行数据源的管理，垂直拆分时把关系紧密（好比同一模块）的表切分出来放在一个库上，或者经过hash进行拆分，从而将原有数据库切分红相似矩阵同样能够无限扩充的队列。

y轴扩展，最后就是功能分解了，也就是咱们讲的微服务切分。微服务拆分将巨型应用按照功能模块分解为一组组不一样的服务，淘宝的系统当年也经历了这样的过程，经过五彩石项目从单一的war包拆分红了今天的你们看到买家，卖家中心，交易等系统。

引入微服务前你要知道的两三事：
**
一、成本升高，引入微服务架构，须要对原来单一系统进行拆分，1到100之后多服务的部署会带来成本的升高**

二、解决分布式事务一致性问题

之前单一的系统好处不少，一条sql解决完成全部业务逻辑，微服务作完一件事情须要涉及多系统调用，系统间网络的不肯定性给结果带来不少不肯定性，现在天淘宝的系统，完成一次交易下单须要在上百个系统之间调用，如何保证系统的可靠性，以及核心数据如钱的最终一致性是设计之初就要想明白的，这里大多都要借助中间件来实现。

三、微服务的逻辑设计原则

随着不断拆分微服务，以及业务的迭代发展，系统之间极有可能出现混乱调用，因此微服务的顶层设计显得尤其重要，架构师须要搞清楚微服务的架构模型。那核心的设计思想就在于如何进行服务的分层，以及服务的重用，经过分层将服务进行分配，上层服务包装下层服务，下层服务负责原子性的操做，上层服务对下层服务进行业务性的组合编排，必定要理解业务，微服务拆分不是简单的系统组合，再说一遍必定要理解业务，不然上层服务必定会出现大量的交叉调用，系统复杂度会指数级上升，好的微服务架构师必定是业务架构师，基于业务的建瓴，微服务设计三部曲，遵循自下而上的设计原则：

原子服务

首先确认最基本业务最维度的原子服务，原子服务定义就是你们都会最大化重用的功能，须要在应用内的闭环操做，没有任何跨其余服务的分支逻辑，杜绝对其余服务的调用，有本身独立的数据存储，做为最底层服务抽象存在，以淘宝为例，卖家数据，卖家数据，订单数据就属于最基本的原子服务。

服务组合

在业务场景下，一个功能都须要跨越多个原子服务来完成一个动做。组合服务就是将业务逻辑抽象拆成独立自主的域，域之间须要保持隔离，服务组合会使用到多个原子服务来完成业务逻辑，如淘宝的交易平台会调用用户，商品，库存等系统。

业务编排

最外层就是面向用户的业务流程，一个产品化的商业流程须要对组合服务进行逻辑编排来完成最终的业务结果，这个编排服务能够彻底是自动化的，经过工做流引擎进行组合自动化来完成特定SOP定义，这对企业应用的自动化流程改进也颇有意义。如淘宝类目的双十一活动，经过对不通服务组合进行重用实现不通的营销活动逻辑。

四、运维管理的复杂度提高

微服务让应用数量增长不少，链路的集成、测试、部署都成为新的挑战，之前一个war包解决的问题，须要经过多应用发布来完成，发布时服务之间的依赖影响，会致使功能不可用，测试阶段的依赖性可能会让用例跑不下去，这些都会是须要新考虑的问题，须要有平台化的工具来支撑，目前阿里经过aone产品来保证从平常到预发到线上的持续集成交付。

实践：
目前不少微服务经过DevOps和Docker来落地， 也能够借助云上FAAS平台来实现，如AWS的Lambda，阿里云的Bazaar，均可以把Function发布成一个Service，结合云效系统来进行服务整个生命周期的编排，能够极大的提升工程效率，实现应用微服务。

 

阿里云总监系列课重磅上线！聚焦人工智能、弹性计算、数据库等热门领域，首次集齐12位阿里云技术高管，耗时半年精心打磨，从理论到实践倾囊相授，从零开始绘制技术大牛成长路径，限时直播课程免费报名中！