架构师是什么呢？在我的认知里面，应该是一个技术的统筹和规划者，这个职位存在的意义，就是为了统筹现有的技术架构，规划未来的技术发展。一个优良的架构师需要掌握的知识量是很庞大的，但，说到底这也就是一个职位的名称，最终的目标依然是为了解决问题而存在的（虽然这是一句废话，但是这就是工作的本质，为了解决某些问题才会设置具体的岗位名称的，只是架构师是为了解决更大的技术难题而存在的）。
一个良好的架构师需要具备那些技能，这就是一个见仁见智的问题，因为岗位的职责就是不一样的，架构师也总会遇到一些完全没有接触过的东西，这个时候就体现出架构师最大价值的时候了。即便如此，有些东西依然是一个架构师应该了解并且非常清楚的内容。现在花点儿时间把过往的内容总结一下，先写一篇总的思考，后面会陆续写出来的，希望不是一个坑。
现代的技术架构技术栈，从本质上来说就是 数据- 应用-前端 的组合，然后根据具体的业务场景和经验来选择就可以了。
数据端
数据端，简单来说就是存储数据的，也就是数据库，当然不仅限于数据库，还可以使用其他的东西来存储数据，比如可以使用文件、内存等存放数据，但是如果考虑高效读取或者永久化存储数据，选择一个合适的数据库就显得很重要了。现在常用的数据库主要有两类，一类是关系型数据库，比如mysql、oracle、sql server等常见的数据库；一类是非关系型数据库（即nosql），比如mongodb、redis、cassandra等数据库。具体选择那种数据库就需要根据具体的业务场景来分析处理，每一种数据库都有其适合的应用场景。如果是业务刚刚开始的情况下，一般都是直接选择关系型数据库，因为从关系型数据库转到nosql比从nosql转到关系型数据库相对容易的多。
应用
应用，一般都是代指后端应用，完成数据的读取和处理，接受和反馈给前端处理过的数据内容，当然不一定非要有后端应用，在有些场景下前端也可以处理数据。这是一个技术喷薄的时代，现在的后端应用有很多，比如Go、Java、node、PHP、Python等等，目前，主要的使用场景还是偏Java，其他的都只是了解，后面会单独抽一篇文章来详细介绍这个。综合来说，不管是设计高并发高负载的系统来说，瓶颈其实并不仅仅在后端应用上，而在于后端的整体架构上，这个才是真正限制的地方。后端应用因为选择多，所以在考虑的时候就会考虑很多，比如团队的主要主要技术语言是什么，该语言的社区支持等等，比如你的团队主要的技术能力是Java，你就不可能选择PHP。
前端
前端负责的是数据的采集和展示，包括web端、Android、iOS等等，虽然我知道还有其他的端，但是我只接触过上面的三种，目前我的技术栈也就仅限于上面的三种。随着无线应用的发展，前端在过去的时间里同样经历了蓬勃，比如web端的Vue、React、Angular，现在的web已经不再仅仅局限于简单地html了，现在的web开发也不再仅仅局限于展示在pc端了。混合开发、Weex、React Native、hybrid，针对移动端的发展也有很多，但是原生应用依然是最佳的选择，这是无可置疑的。
架构
上面只是说了，关于各种关于技术栈最基础的东西。现在说说如何把上面提到的东西整合起来的架构方法，这就是一个架构师该做的事情，上面的技术栈选好之后，就可以进行开发，但是这三者之间如何配合呢？当设计好数据库表时，对于Java而言，可选的数据库连接池就有很多，目前最高效的应该是HikariCP，目前Spring boot2.0就默认集成了HikariCP，其实对于整体架构而言，整个系统最大的限制其实是在对于数据库的增删改查上，增加CPU、内存，创建数据库集群等等都是增加数据库性能的办法。
然后后端应用和前端配合之间，现在更多的使用Restful风格来设计API的，使用的SOA、SOAP、RPC等等还有很多，除了restful之外，与我而言都是需要增长知识点的东西。
运维
高可用，易拓展，是一个系统有着良好发展以及可维护性的很重要的一点。对于一个不稳定的东西，是没有办法去使用的，持续集成和持续交付的设计，就关乎一个系统能够有多稳定的运行下去。
上面其实说了很多，但都是一些很基础的内容，也是自己的一点儿思考，当然也还有很多不足的地方。虽然，我现在主要想往Java架构的能力上走，但是需要学习的东西依然还有很多，后面会一一补上来的。以及，最近自己的阅读计划《知识的错觉》、《数据的本质：无人不是分析师》、《靠谱》，不得不感慨，时间总是那么少。
