2018年度的技术总结
背景
新年了，按惯例，要盘盘肚子里面的“存货”了.
2018年度已掌握的技术学习
已初步掌握的技术的进展，即具体技术流水账：
java
代码写的有点少，spring boot2.0、spring cloud2.X没有过多的深入和落地。
go语言
没有很深入的学，就学了gin、go-kit的皮毛、了解协程的调度。
后端中间件技术
mysql
还是有点云里雾里，还是没有彻底搞清楚线程模型，线程调度
rabbitmq
还是有点云里雾里，还是没有彻底掌握
redis
新学了一个codis的方案，这个方案有点重，有些命令用不了，比如keys *（没有从group做聚合）
zookeeper
还是保留在会用的阶段。
elasticsearch
还是保留在会用的阶段。
elastic-job-lite
elastic-job-lite整个流程，看了一遍源码。
keepalived高可用技术
这一年没有什么进展。
系统工具-centos技术
这一年没有什么进展。
后端技术
注册中心和配置中心
还是eureka，配置中心还是用的携程的apollo，至于阿里云的nacos，继续跟进吧。
docker和kubernetes
这一年，开始捣鼓portainer和kubernetes。下半年的时候，花了一些时间捣鼓了一下kubernetes,并结合之前的技术方案，捣鼓了一套基于apollo+kubernetes方案（后面发现社区有公司也是采用类似的方案）:见本文附录。
总的感觉，kubernetes是个好东西。如果要推动，需要自上而下的推动。现在这个产品驱动开发的公司，技术老大的重心由偏向于产品层面，所以，只能在线下玩一玩。
如果要推动，需要自上而下的推动。现在这个产品驱动开发的公司，技术老大的重心由偏向于产品层面，所以，只能在线下玩一玩。运维做的有点多了。
监控跟踪技术
容器监控技术
还是比较熟悉prometheus。也了解了cadvisord技术和influxdb技术。
zipkin技术
链路监控还是比较熟悉zipkin。
应用监控和中间件监控
还是比较熟悉prometheus。
中间件技术架构方面的收获
应用架构方面的书籍
本人工作伊始，到现在一直都有接触各种“架构”模式：SOA、分层、服务化、微服务、云原生。相关的词汇陈出不穷。
所以，今年花了比较多的时间在理解云原生与微服务的区别（后面发现其实没啥本质区别，就是升级版）。并读了一本质量还行的书《云原生架构下的微服务最佳实践》。
综合评价
先说综合评价，这本书还是有点货的，里面的很多技术是可以引入到项目的技术体系。
如果让我推荐，我会推荐读。然后，根据组织结构，去各个技术的官方站点，看官方文档，仔细的撸一遍代码和命令。
这本书的组织架构
从这本书的组织结构，可以看出，这是位有“货”的架构师。从传统架构谈到了:
- 架构模式（云原生、微服务）
- 公有或者私有云(一笔带过)
- 云上技术基础设施（数据库、缓存、消息中间件、任务调度中间件、自动化、持续集成、监控、框架、分布式ID）
- 分布式系统面临的一致性
- 分布式系统面临的可用性
- 分布式系统面临的扩展性
- 分布式系统面临的性能
- 未来值得关注的方向
- 研发流程、组织结构、研发文化
这本书的槽点
下面本人将按组织结构的顺序进行点评。
架构模式
本书花了6页的篇幅，探讨云原生的概念。个人认为还是比较浅，还可以深入点。后面又花了40多页的篇幅探讨为什么要引入微服务架构、微服务设计原则、实施的先决条件（很重要的一个点）、服务划分模式、接口设计、接口可视化（对于团队开发很重要）。基本算是合格。
公有/私有云
有点遗憾，这块基本上是一笔带过。
其实还是可以提一下GCP、AWS、IBM、Azure（毕竟公有云现在如日中天）、基于openstack或者kvm组成的私有云，以及基于这些云上的容器云技术kubernetes。
云上技术基础设施
云上技术基础设施：数据库、缓存、消息中间件、任务调度中间件、自动化、持续集成、监控、框架、分布式ID。
这些技术分成了第二章的后半章、第三章整章来说，个人认为，从篇幅上是很不够的。应该是每个技术安排一章。
不过也理解，纸质书籍有其局限性，还要出版社方面的考虑。
因为纸质书籍的局限性，给了博客一些机会，本人的博客，也细化了这些技术。
分布式系统面临的可用性
谈到了几点：可用性的几板斧-重试、流控、熔断、容量预估、隔离。
至于服务端入口处的高可用，没有谈论到。
分布式系统面临的可扩展性
谈到了一点：AKF。
没有记错的话，架构即未来也谈到了这个方法论。
分布式系统面临的性能
性能这块，其实就几板斧：同步变异步、缓存、数据库分库分表、消息队列。
分布式系统面临的一致性
本书从传统的定义引入分布式系统的一致性，然后做了分类（数据为中心的一致性、用户为中心的一致性）。然后讲了两阶段提交的局限性、三阶段提交的局限性。以及业界常用的几种解决方案：
重试机制、本地记录日志、可靠事件机制、TCC事务模型。另外还提到了分布式锁。其实分布式锁、分布式id、可以单独起一章讨论。
后续值得关注的技术、组织文化、研发流程
至于这块，当小说看了。尤其是组织、研发流程变化，最好是自上而下的推动，而不是自下而上。
形成自己的通用中间件技术架构图
形成自己的业务平台通用中间件技术架构图: