《架构师》期刊摘要(2016年)一
一、《软件设计精要与模式》作者张逸在接收InfoQ采访时曾说:“评价一个架构的优劣方法之一是,把每个功能、非功能的因素扩大化,再看这个架构会不会出问题。”(本人赞同此说法)他的观点是说,架构设计要面向业务未来,而未来是不断发展的。架构不仅要承载业务的增长,还要兼顾技术发展的趋势。
《前言》(2016年6月)
二、我想任何人做架构多需要秉承“业务需求决定技术演化路线”的思路,那些暴露出来的现状和问题都驱动系统去转型,在系统和人之间找到一种最佳的合作模式,匹配已有的生产力和生成关系。正如软件开发学泰斗Kent Bech所说的:设计,是让你在长期过程中保持软件变化更加容易。
在体量还不大的情况下,首先应该解决的是搭建好一套绝对稳定的基于模块化的平台,待体量逐渐长大、再去根据实际需求进行拆分、团队也随之变化。再下个阶段体量大道饱受单体模式智库,也应该首先建设平台服务,建设好之后,先按照大的粒度进行拆分,逐步再微服务化,否则,直接上服务化甚至微服务化都是非常危险的。
微服务化就是以一系列小的服务开发支撑一个应用的方法论,服务独立在自己的进程中,通过轻量级通信机制交互(通常为HTTP),这些服务时围绕着业务上的组织结构来构建的,全自动的、独立部署。几乎看不到中心化的服务管理基础设施,可以使用不同的编程语言和数据存储技术来实现不同的服务。
《Building Microservices》一书中提到“微服务化就是一堆小而自治的服务,让他们一起工作起来”。微服务化的特点在于:
1、模块即服务
微服务中的组件在逻辑或者物理层次更趋于细分,这个细分不是极致的,而是一种力度适中的选择,通常这些组件在前期可以是一些模块,但是当需要时,例如业务上需要拆分独立,或者非功能需求上需要扩容等,都可以灵活的拆解出来。
2、独立自治
这意味着服务独立开发、独立测试,独立发布、独立部署、独立运维的,某个细分团队负责整个生命周期管理,这就是“康威定律”的通俗解释,官方解释是“一个组织的设计成果,其结构往往对应于这个组织中的沟通结构”,服务的规划不就是多人、跨团队协作的沟通模式吗?
同时去除了牵一发而动全身的问题,单一职责的来进行修改需求或者重构一个点,开发和构建方便,不影响整个产品的功能,一个bug不会crash掉整个产品,针对不同的类型,区分“计算密集型”还是“IO密集型”,区分业务上更好使用关系型还是NoSQL,区分2/8原则(即80%经常修改的服务独立出来自成一家),区分短板功能、针对瓶颈可以做水平扩展、避免资源竞争,甚至可以区分技术栈、突破语言限制独立的服务可以实现非常大程度上的复用,服务之间依赖轻量级的接口,而不是模块。
3、去中心化的数据管理
微服务在服务拆分的同时,也需要将数据库分离,独立的服务维护独立的数据库,这对数据库也是减负,同时技术选型、SLA保证都会区分开来,把精力留给那些重要的业务数据库,进行分级的对待,而不能像以前那样一视同仁,一个不重要的逻辑库的bad SQL慢查询,阻塞了其他正常的查询,这事完全可以避免的。
4、轻量级的通信协议
传统的SOA使用ESB或者WebService这种重量级的解决方案,微服务推荐使用一些更轻量级的解决方案,要通用性,可以用RESTFul架构,使用HTTP通道,支持JSON序列化协议;需要高性能的,可以考虑使用高性能IO模型,比如Epoll、Actor等,基于TCP通道,使用protobuf序列化协议,同时保持长连接;要异步,可以通过持久的RabbitMQ或者高性能的ZeroMQ来做P2P、pub/sub等。而这种轻量级还需要体现在代码调用中,模块化直接通过函数、方法调用即可,服务化后能不能在API层面做到无侵入、无缝切换、简单配置,这些都是服务化框架要支持的。
5、为失败设计
服务化,因为着调用时跨进程的、分布式的,这种分布式特性引起的天然不可靠性,需要变为相对可控。也就是服务间的通信要架设不会成功,为失败处理。
为了不影响整个产品,要做错误隔离,可以考虑熔断(circut break)、船舱隔离模式、限流、回退等手段,最后还有幂等性等问题(重试会不会对业务造成影响)。
6、基础交付设施自动化
这个特点是整个微服务中最大的亮点,包括持续集成CI、持续交付CD和Pass平台结合。微服务在细分的背景下,在project结果、物理结果上都提高了一个复杂度,就需要在基础交付上做一个大的转变,自动化部署则是必须的。
微服务的缺点:
1、分布式调用造成的性能、延迟问题。(可以采取的措施包括粒度适中、批量、高性能RPC、异步通信等)
2、可靠性不好保证。(为失败而设计)
3、数据一致性难以保证。(分布式设计本身涉及到的问题,最终一致性、强一致性等)
4、整体复杂度提升。服务多、依赖多、调用多、契约如何管理、监控如何做,调用链上怎么确定哪个点有问题,服务的SLA保障、性能、错误率、告警、集成测试、部署等。
架构只是标准、骨骼,对微服务的讨论不应该让我们忘记了更重要的问题,驱动软件项目成功和失败的重要因素。软因素,比如团队中人的素质、以及他们如何彼此合作、沟通,这都会丢是否使用微服务有很大的影响。在纯技术层面上来讲,应该把重点放在干净的代码、完善到位的测试,并持续关注架构演进,这才是一个软件工程师的根本职责。
《谈谈后端业务系统的微服务化改造》(2016年6月)
三、传统的企业级应用是单体应用,一般是分层结构,如表现层、应用层、领域层、数据层,这主要是水平切分的思想。
随着互联网应用的发展,特别是大型电商系统,业务非常复杂。这种巨型系统,首先要关注的是如何根据业务划分子系统,然后是子系统间如何协作,最后才是子系统内部实现。SOA设计可以有效支持前面两步,在SOA体系里,每个子系统是独立的服务,服务接口体现子系统协作关系,至于子系统内部,直接作为黑盒处理。
所以对于复杂系统,首先采用SOA垂直切分子系统,然后使用分层设计水平切分大单个子系统,服务化把传统的分层设计往前更推进一步。
当然SOA本身也在不断发展,最初跨企业的Web Service交互可以认为1.0时代,支持企业内部系统间轻量级访问、支持服务治理,可认为是2.0时代;服务进一步分层和微服务化可认为3.0时代。
“业务在变,技术在变,架构也在变。变的是形式,不变的是本质,架构为了系统更有序,系统为了业务更快速,业务为了生活更美好”。
《卷首语--架构发展趋势和现状》(2016年三月)
四、
“KumuluzEE是第一个使用标准Java API的微服务框架。微服务架构的重点是将应用程序开发成服务并将这些服务单独部署;没有一个框架提供自动化部署和配置,是不可能使用JavaEE实现真正的微服务架构的”。