本次主要讲以下三个方面的内容：
1. 微服务架构的核心思想，以及从SOA到微服务架构的演进过程，两者的区别。
2. 微服务架构实现中的核心部件微服务网关的核心功能分析和说明
3. 企业进行微服务架构实施可行的演进路线，以及在实施过程中可能存在的潜在风险分析。
首先来看下微服务架构核心思想部分的内容
在讲微服务架构之前首先还是要介绍下SOA核心架构思想，微服务架构本身也是从SOA架构思想演进过来的。对于SOA经常说的定义就是，将支持企业IT的业务系统分解为多个组件，让每个组件都独立提供离散，自治，可复用的服务能力；同时通过服务的组合和编排来实现上层的业务流程。
这里面有两个重点，其一就是找到服务，其二就是组合和组装服务。对应到企业里面的实践也可以总结为业务能力组件化，组件能力服务化，服务能力可编排化。
我们来看一个新公司注册的例子来说明下SOA的核心，你要完成一个新公司注册一定涉及到根工商，税务，银行多个政府部门和金融单位业务协同才能完成。要完成协同首先各个业务部门要将自己能力暴露为服务，即找到服务的过程。
找到服务后，我们再跟进业务流程需要将服务组装起来，形成一个完整流程。
常规我们谈SOA的时候都是谈业务系统间的服务共享和集成，即最小管理单位是业务系统，如采购系统，ERP系统。但是如果进一步我们将管理最小单元变化为组件，即采购系统里面的采购订单组件，供应商组件，那这就是SOA思想进一步内化到业务系统内部。而正是由于此，引出了微服务架构。
对于微服务你可以理解为将传统单体应用打散为多个松耦合微服务模块构成的架构模式，微服务模块完全独立自治，并通过轻量的HTTP API接口进行业务和数据协同。
所以要解释微服务架构，首先你要看传统单体应用究竟存在什么问题，如上面的图。
很多单体应用有时候也在强调是基于组件化和模块化的开始思路开发的，或者说是基于SOA架构开发，那从运行态和设计态分别来看的话可以看到。
从运行态的视角：
1. DB走HA或RAC集群，但是扩展性是大问题，很多应用后期即使走了RAC也无法解决性能问题。
2. 部署的是一个大WAR包，无法分模块独立分开部署。
3. WAR部署当前可以是物理机，也可以是虚拟机，但是WAR包偏重，很少直接部署到Docker容器的。
4. Application Server层的性能可以通过负载均衡方式进行水平扩展。
从设计态的视角：
1. DB本身是无法拆分的，各个模块的数据库，视图全在一个大的SID或Schema里面。
2. 模块之间的交互除了通过逻辑层外，还有些是直接通过DB层的跨表连接完成的。
3. 逻辑层的模块和模块之间往往是紧耦合的，相互间的调用随意，很多都是内部API或方法调用。
不管是从运行态还是设计态来看，传统的单体应用最大的问题就是各个组件和模块之间紧耦合，而这种耦合带来的问题就是扩展困难，升级和变更困难（模块间相互影响大）。
其次，传统单体应用面临的第二个问题是展现层和逻辑层的紧耦合，而实际在当前应用架构设计和开发中，可以看到需要同时满足电脑，平板，手机APP终端等多种前端展现和访问。而这种访问必须是支持分布式的接口服务访问模式。传统单体应用要做到这点也只有进行改造，比如再单独增加一个服务代理组件来发布服务。
传统单体应用到微服务架构
正是由于传统单体应用存在的一些问题，微服务架构提出了将传统单体应用打散为多个离散，自治的独立组件。这些组件你可以称呼它为微服务模块，这些微服务模块本身需要满足的就是从数据库，到逻辑层，到界面展现层都能够是独立的一套；微服务模块能够从需求，设计，开发，测试，部署上线和运维都相对独立。
这个思想本质仍然是SOA架构思想和组件化思想在业务系统内部应用的体现。基于以上思考，传统单体应用转变为微服务架构后如下图所示：
从运行态的视角：
1. 数据库在部署的时候是可物理拆分的，即不同微服务模块的数据库可以独立部署。
2. 微服务模块的应用组件包是独立部署的。
3. WAR包由于已经按模块拆分为多个，因此每个WAR包相对来说更加轻，而容易部署到类似Docker容器上。
4. 由于WAR包之间有接口交互和协同，需要增加微服务网关实现服务管理和治理。
从设计态的视角：
1. 数据库，逻辑层和界面展现在设计的时候就是完全相对独立的一套。
2. 逻辑层的各个组件之间只能通过Service API接口进行交互，微服务架构下推荐轻量Http Rest接口。
3. 逻辑层各个模块之间彻底实现松耦合。各个模块本身也更加轻量。
基于上面的分析可以看到，微服务架构本质仍然是SOA架构思想在业务系统内部的实施，即SOA思想不再是局限在业务系统间，而是已经显性表现在了业务系统内部的各个业务组件间。但是SOA架构思想又不是微服务架构全部，里面还涉及很多组件化和领域建模思路，这个在考虑系统间集成的SOA项目中往往并不会太多涉及。
因此你可以将微服务架构思想理解为 SOA架构思想+组件化思想+领域建模思想的组合。我们很多时候在谈微服务架构的时候都在谈是否用了Spring Cloud, Spring Boot框架，是否走的Http Rest接口服务，这些都是技术层面的内容，如果前面这些组件划分和领域服务识别定义这些工作没做好，那实际上是一种假的微服务架构。正如原来很多人认为用了WebService接口就是SOA一样的道理。
从ESB企业服务总线到微服务网关
我们在实施SOA项目时候，谈的最多的就是基于ESB服务总线的集成平台或服务共享平台。ESB服务总线可以理解为将传统的单点集成转化为总线式集成的核心部件，它是企业内部业务系统间业务协同和数据集成的高速公路，通过将所有的服务注册和接入，来实现对所有服务运行的管理和监控，在这个过程中提供了服务注册，适配器，协议转换，消息格式转换，消息集成，数据映射，简单服务编排，安全认证，日志，流控等多种能力。
而对于微服务架构下一样，仍然需要对微服务架构进行统一管理，只是在微服务架构架构下都是标准的Http Rest接口和AMQP消息接口了，对于传统的服务适配和协议转换等没有了，同时对于服务的编排这种重的能力也不再需要。那么更多的将体现在对服务的管理能力上。这种管理能力包括了服务的统一注册和发现，服务安全，服务集群和路由，服务限流，日志等能力上。
在谈微服务架构的核心组件的时候，有文章会把服务注册和发现，微服务网关，服务限流和容错能力并列，而实际上我们完全可以将上述能力全部做为微服务网关应该具备的能力。这些能力有些是在引擎层面的，有些是在管控层面的，都必须要具备。
对于微服务网关涉及的内容今天不做太详细的展开，只讲一些核心功能组件和要点说明。
首先看下服务注册和发现功能，即网关要提供一个功能将微服务模块暴露的Http Rest API接口能够快速的注册和接入，以变提供统一的服务目录库能力。对于服务注册可以是手工注册，但是也可以是动态自动注册，特别是微服务架构和Docker容器结合的时候，必须要实现服务动态注册过程，即当动态自动扩展部署了一个新的微服务模块集群节点的时候，这个节点提供的微服务接口能实现自动注册到微服务网关上。
在服务调用的时候可以看到，首先查询服务注册中心，在从服务注册中心查询拿到地址后发起对目标系统的服务调用。这种模式下可以看到鉴权和获取服务地址过程与实际的服务接口调用过程是分离的，也就是说控制流和数据流是分离的。类似Dubbo总线的实现即是上面这种模式。
在这种模式下虽然微服务网关的性能很高，但是有两个大缺点，其一是无法对数据流日志进行详细监控，其二是源服务接口IP仍然向外暴露，无法真正做到SOA思想常说的访问位置透明。如果是涉及到外面互联网接口协同，这种模式存在很大安全隐患。
微服务网关统一接入和注册服务后，自然提供对外统一的服务目录库，即在SOA里面常说的服务代理能力，将源服务简单代理再包一层厚发布为统一IP地址的服务目录库。如下：
除了这个最基本能力外，微服务网关本身还提供如下能力：
服务反向路由，就是我上面谈到的服务代理，提供统一服务目录库。
安全认证和防爬虫，所有外部请求必须经过网关，网关可以集中对访问进行安全控制，比如用户认证和授权，同时还可以分析访问模式实现防爬虫功能，网关是连接企业内外系统的安全之门。
限流和容错，在流量高峰期，网关可以限制流量，保护后台系统不被大流量冲垮。对于容错一方面是通过消息中间件缓存，一个是直接对服务进行熔断处理。
监控，网关可以集中监控访问量，调用延迟，错误日志，集中化网关还可以监控数据日志。所有这些监控日志都是后续服务性能优化分析的重要参考。
其它能力：实现线上引流，线上压测，线上调试(Surgical debugging)，金丝雀测试(Canary Testing)，数据中心双活(Active-Active HA)等高级功能。
从这些能力提供来看，微服务网关相当强调了服务流量控制和容错方面的能力，因为一旦这个能力实现的不好会导致整个处于中枢地位的微服务网关垮掉。基于上面讲的内容，我们可以这样理解ESB和微服务网关。
微服务网关 = 传统ESB + 去掉了复杂服务适配和协议转换 +去掉了服务编排 + 提升了限流容错能力
最后我们再来简单谈下企业实施微服务架构的策略和演进思路
由于微服务架构管理的粒度已经到了业务系统里面的一个个组件，因此企业在自身IT成熟度还没有达到一定水平的时候，应该谨慎对待微服务架构，其核心原因就是由于架构微服务化后会导致开发，集成，乃至后期的运维管控的复杂度呈指数级提升。即使企业本身有组件化和服务化的思想，但是也没有能够彻底构建微服务架构的能力。
任何事情都要考虑从简单到复杂，通过迭代的方式逐步演进。对于可行切入点可以从以下几方面考虑：
1. 共性技术服务能力下沉建设
企业在刚开始规划建设，或者建设到一定阶段后，都会涉及到一下基础性的共性技术需求，类似消息管理，日志管理，文件存储，共性的小应用组件（论坛，通讯录，文档在线阅读）等。
这些共性能力既可以是技术服务，也可以是共性小应用程序，其最大的特点就是这些组件本身横向交互相当少，而更多的是将自己的能力向上提供暴露和集成。因此这类场景采用微服务架构方式来独立构建并部署是合适的，这类模块的上线和集成可以最大限度的减少对已有横向业务的影响。
2. 基础平台层能力先行
企业在实施微服务架构的时候，一定要意识到对于4A+流程引擎这两个能力需要提取进行平台化和微服务模块化。因为这两个基础能力往往是任何一个业务微服务模块能够运转起来的基础。正是由于这两个基础能力的平台化，我们在构建新的微服务模块的时候，才能够将重心完全放在只关注业务实现上。
3. 新增模块移出
如果企业已经实施了采购系统而且已经上线运行多年，那么在对采购系统出现大的模块级需求的时候（例如需求在采购需求中增加招投标的功能），那么这种模块需求就可以考虑移出采购系统，通过微服务架构的方式独立构建，在构建完成后在和采购管理系统集成。
对于一个新增模块是否能移出，重点还是要考虑该模块和已有的遗留业务系统间的耦合性和集成度。耦合度越小，越容易单独构建并后期集成。从这个角度来看对于哪些在原有业务系统中上游业务最适合移出，例如招投标模块构建只是需要将合格供应商和采购物料清单信息传递到采购系统，而并不需要从已有的采购系统返回任何信息。
4. 大变更下模块移出
企业在接收到新的变更需求处理时，当已有业务系统的某一个模块出现重大变更时（比如变更内容和范围超过了模块本身30%-50%），在这种情况下可以考虑将变更模块移出并进行微服务架构的改造。
要清楚在模块大变更情况下，即使按原有模块开发和处理，也会带来巨大的模块开发和集成，联调和实施工作量，还还不如和企业微服务架构演进策略一起处理。两次对业务的大影响变成一次影响，虽然增加了复杂度，但是实际上是降低了整体工作量和后期迁移难度。
对于企业实施微服务潜在风险，大家可以参考之前的企业应该谨慎对待微服务架构这篇文章。
培训目的 TOGAF?鉴定级培训的学习目标聚焦在让学员系统的学习业务架构、数据架构、应用架构和技术架构基础知识与理解之外的分析与应用。 鉴定级认证的目的是证明学员除了具备基础级的知识和理解能力，还能够分析和应用这些知识。 目标对象 企业IT部门负责架构相关工作的项目经理或技术人员； 在已经采用TOGAF 9.1组织中工作和必须参加架构项目和主创活动的专业人士； 将负责开发架构制品的架构师； 想更深入地了解TOGAF9.1或有意愿引进TOGAF 9.1、成为实际应用架构的架构师个人。 课程特色: 1. 理论与实践相结合、案例分析与行业应用穿插进行； 2. 精彩内容解析、学员专题讨论、分组研究； 3. 全面知识理解、专题技能掌握和安全实践增强的授课模式。 2017年4月24-27日 北京
联系客服
