标签：注册 ack 实现 适合 研发 技术人才 公有 单点 3.1
面对微服务如火如荼的发展，很多人都在了解，学习希望能在自己的项目中帮得上忙，当你对微服务的庐山真面目有所了解后，接下来就是说服自己了，到底如何评估微服务，什么时候使用微服务，什么时间点最合适，需要哪些技术储备和资源投入等等，这些都是你需要面对和解决的。
本文从单体架构，微服务架构，微服务风险评估，微服务落地条件等几个方面探讨微服务的落地过程，希望对你有所启发。
讲解微服务之前，我们先简单了解下单体架构。
随着业务的复杂度增加，单体的灵活度会逐渐下降，比如：
架构设计的三大原则告诉我们，架构需要的是简单、适度、演化。
对于项目起步阶段，单体是最高效也是最节省成本的方式。因为初期阶段，由于人力，成本，业务熟悉程度，微服务技术积累等因素，如何过度设计可能工期和复杂度会急剧上升，造成交付困难，问题百出，从而错过了时间窗口。最合适，简单的方式还是单体优先，这是创业公司的特点决定的。当然设计面向微服务的单体架构也是一种聪明的方法，这遵守了系统演化的法则。
无论采取何种维度的架构分层，分层的最核心目的是保证各层之间的差异足够清晰，边界足够明显，为将来可能产生的变化提供最容易、最小化的修改。比如客户端要从安卓替换为IOS，底层无须任何改动，就像替换积木一样。又比如，设备需要接入新的设备或协议，其他层也不需要做任何变化，可以无缝平滑接入任何设备。
如果前期在业务不十分清晰，求的是验证想法，证明产品思路是否可行性，并且业务量不大，仅限于省级范围，建议只要对当前架构稍加改良升级就可以了，这样改动量相对较小，且至少能支撑一定时间段的业务增长。
支撑的业务更加庞大，可以支撑海量用户高并发和海量设备接入，支持分布式多机房，多区域部署，支持服务器无限扩容。支持私有云，公有云，混合云等部署方式。所以微服务是大多数互联网公司的首选。
微服务架构图谱谷歌或Bing下，可以看到各种各样的架构图，源于业务和架构师自身的喜好或者粗细粒度，但是每个架构图的基本组件和架构分层都差别不大，只是有的细一些，有的粗一下。比如有客户端层，容器层(K8S)，API Gateway，微服务集群层，EventBus层是必须要有的，至于服务监控和服务跟踪、服务治理本身就是一个完整的系统，粒度就没有细了。基于这些概念，我把架构图稍微细化一下，这里省去服务监控跟踪和治理的部分，后续单独抽离出来分析。
这边的架构图谱相对之前的架构图，更加贴近业务，粒度也更细，虽然个别组件有所省略，比如跟踪和治理部分。
以上架构图主要分4层，每个层次遵循架构分层的核心思想：关注点分离，职责各异，边界清晰。
第1层：客户端：理论上包含一切可以联网的设备，包括移动设备，Android、IoS、Pad、微信、微博、QQ、Web、各自浏览器、物联网设备等等……
第2层：API网关：包括服务注册，发现，认证授权，单点登录，熔断，限流……网关的知识点丰富，是微服务的核心之一。
第3层：微服务集群：包括各种具体的microservice，比如纵向划分的业务服务(用户服务，订单服务，……)，横向划分的基础或公共服务(元数据服务，公共服务……)
其他微服务的地址可能是这样的：
第4层：事件总线：Event Bus 目的是消息解耦，不要让服务之间直接的链接。不同与SOA的服务总线，事件总线相对比较轻量，经常基于消息队列引擎进行解耦，目的是为了让服务之间的关联弱化，不直接进行关联。很多时候用的是相对稳定、可靠、企业级的RabbitMQ。
微服务的架构其实不难，根据以上的架构，每种业务都可以进行套用，这里的难点在于服务的划分和粒度控制，另外如何管理膨胀的服务是一个麻烦事。
这里引用架构师杨波(前Ebay架构师，目前任职拍拍贷研发部总监，资深技术架构师，微服务技术专家)的一些观点：
一般情况下，业务系统引入新技术就必然会带来架构的复杂度提升，在具体决策前，你先要认识到新架构会带来哪些新的问题，这些问题你和你的团队是否能够解决？如何解决？是自己投入人力建设，还是采用业界开源方案？假如你和我一样都是微服务的旁观者或者学习者，那么下面的评估也许对你又所参考。
不同的落地方式决定不同的资源配置。
方式一：借力外部架构咨询公司提供架构DEMO和培训服务助推内部团队技术转型升级。
方式二：招聘相关经验丰富的人员进来，自行研究和搭建架构并做内部培训，推动团队技术升级。
建议：如果比较紧急，采用第一种方式，因为招聘匹配的人才比较困难，等不起。但是不管是那种方式，对于团队来说都需要一定的技术人才储备方便后续交接和运维。
这里分成两类人员，一类是研究型，一类是应用型。研究型主要是以技术攻坚为主，负责微服务的核心组件的研究和开发，比如服务发布和订阅，服务跟踪和监控，服务的治理；应用型主要是负责技术理解应用为主。
微服务相关技术栈和微服务周边技术栈。周边技术栈包括领域驱动涉及，持续交付，分布式至少，负载均衡，CAP理论，缓存原理，DevOps和容器化技术。
杨波在给微服务的开发团队规划时候给了一个百人左右的大概预估，至于到底需要多少开发人员就没有细说，可能作者本身呆过的公司都是大厂，对人力成本控制没有那么大的包袱，对于中小企业，人力是最贵的成本。如果要一定要上微服务，该怎么办？
由于是架构级别的调整，之前能保留下来的大部分是解耦比较好的代码，比如前端代码，采集服务代码，部分业务逻辑代码，所以对现有框架冲击面比较大。
因为微服务是一种观念和思想，又是新近技术，本身就有各种架构实现方式和技术解决方案。所以对技术人员来说，对比选型本身就是一个考验。加上本身涉及的技术面就比较广，所以复杂度和门槛相对比较高。
但是该技术发源于亚马逊，经过近些年的发展，虽然还在发展，但是已经相对成熟。
微服务架构工作量主要集中在后端，对后端开发人员的技术级别有较高的要求，主要是对微服务原理和开源组件的熟悉上，同时需要具备整体的微服务的意识。暂时不具备整体微服务开发意识和经验，需要通过培训后进行转型升级。
如果采用借助外部架构力量来助推架构升级，和架构单位的合作就不是简单的外包，涉及的面会变得比较广，在完全交接过来之前，周期会比较长。包括对我们业务架构的深入了解，然后根据业务架构绘制可靠技术架构蓝图，再根据技术蓝图进行落地实施(不建议只提供架构方案而由其他单位实施落地)，包括新系统的开发，旧系统的升级，当然这种升级是平滑过度的，对业务窗口并不会产生影响。
如何正确拆分？这里正确指的是合理，因为没有绝对的标准。按照前人的经验可以分为纵向和横向两种划分方法：
是从业务维度进行拆分。标准是按照业务的关联程度来决定，关联比较密切的业务适合拆分为一个微服务，而功能相对比较独立的业务适合单独拆分为一个微服务，比如上图中的订单服务，用户服务。另外粒度太小，服务聚合是一个坑，粒度太大，分和没分一个样。
是从公共且独立功能维度拆分。标准是按照是否有公共的被多个其他服务调用，且依赖的资源独立不与其他业务耦合。比如上图中的元数据服务和消息服务。
借用《微服务设计》中的一句话：“你越不了解一个领域，为服务找到合适的界限上下文就越难……服务的界限划分错误，可能会导致不得不频繁地更改服务间的协作，而这种更改成本更高……”
由于SOA和微服务有千丝万缕的关系，这里简单罗列双方的对比图，算是一个小知识点：
两种架构背后的意图是不同的：SOA尝试将应用集成，一般采用中央管理模式来确保各应用能够交互运作。微服务尝试部署新功能，快速有效地扩展开发团队。它着重于分散管理、代码再利用与自动化执行。
最后让我们回顾一下前人经典的话语：
还是回到我们架构设计的原则上，遵循简单，适用，演化的原则，那么你的抉择也许会变得没有那么令人纠缠。
标签：注册 ack 实现 适合 研发 技术人才 公有 单点 3.1
原文地址：https://www.cnblogs.com/jackyfei/p/10107510.html
