今年新开始我们开始学习了软件架构这一学科，所以特地查看了一下以前的大神的博客园的博客，自己学习一下。
所谓软件架构师，其实就是一个能够根据客户的要求，结合实际能力，将客户的需求转换为专业的开发计划和一系列的要求文本，能够制定一个总体框架，领导一个小组完成这个开发计划，相当于一个计划的灵魂和指向者。
对于一个软件来说，软甲架构师决定了这个软件的全部，到底这个软件要如何设计都是由架构师提前架构出来的。
事实上，架构在软件发明时的N多年以前，就已经存在了，这个词最早是跟随着建筑出现的。所以，我觉得有必要从源头开始，把架构这个概念先讨论清楚，只有这样，软件行业架构的讨论才有意义。
为什么会产生架构，总的来说还是有这个需求，才会产生这个学科，一个人开始工作的时候，可以完成一件事，一群人完成一件事情的时候，每个人就会有独立的分工，每个人的时间有限，每个人的能力有限，所以复杂的目标，完成这个就需要架构，大概就是这个意思。从某种意义上讲，架构是人类发展过程中，从由懵懵懂懂的，被动的去认识这个世界，变成主动的去认识，并以更高的效率去改造这个世界的方法。
了解了什么是架构对于我们来说是十分重要的，构建实际上是解决人的问题，所以软件构架也不例外，最终的目的都是解决人的需求。
一名软件架构使得职责是什么呢？按照之前架构的定义，做好架构首先需要做的就是识别出需要解决的问题。一般来说，如果把真正的问题找到，那么问题就已经解决80%了。这个能力基本上就决定了架构师的水平。当我们告知一个问题时会犯一些常见的错误，比如
1.被告知要处理一个问题，但是交过来的实际上是一个解决方案，不是问题本身。
2.被告知要处理一个问题，直接通过直觉就有了一个解决方案，马上考虑解决方案如何落地，或者有几种解决方案，选哪个合适。
作为软件工程师或者架构师，我们大部分时候是要去解决别人的问题，“别人”是谁，是值得好好思考的。明白了问题的主体，这个主体就自然会带来很多边界约束，这个时候才算是真正的明白了问题。可以想象，这样下去最后的结果一定是大家都满意的，因为真正的问题解决了。只有真正明白了是谁的问题，才能够真正地完成自己的任务，真正地把自己的问题解决掉，而不是反过来。当问题的主体离架构师越远，就会让找出问题主体的过程越加困难。
如果要当软件架构师，必须要知道几点重要的事情，我们要确定要解决谁的问题，首先是业务问题
具体的现实生活状态下，没有软件的时候，所解决的问题的主体是谁，解决的是什么问题，是如何解决，如何运作的？
二、计算机问题
如何把现实生活用软件来模拟？
模拟出来的软件，需要哪些硬件设施才能够满足要求？ 并且当访问量越来越大的时候，软件能否支持硬件慢慢长大，性能线性扩展？
因为硬件是可能会失效的，软件如何在硬件失效的情况下，仍然能够保证可用性，让用户能够不中断的访问软件提供的服务？
怎么收集软件产生的数据，为下一阶段的工作提供依据？
分别是谁的问题呢？
业务的owner需要提升业务的效率，降低业务的成本，这是动机。这个实际上就是业务的问题，所以一般软件开发的出发点就在这里。
是软件工程师的问题，要解决业务owner把业务虚拟化的问题，并且要解决软件开发和运营的生命周期的问题。
作为软件架构师，软甲当然是重中之重，软件架构的出现也是同样的。一开始是懵懵懂懂的去写软件，后来慢慢的就有意识的去切分，演变成了不同的架构。这个背后的动力也是一样的，就是提升参与的人的利益，降低成本。导火索也是软件工程师的任务太重，我们需要把很多工作拆分出来。拆分的原则也是一样的，如何让权责一致。同样，这个拆分也是需要组织架构的调整，来保证架构的落地
软件的本质，其实就是通过把人类的日常工作生活虚拟化，减少成本，提升单个人员的生产力，提升人类自己的利益。软件工程师的职责在这个浪潮中，不堪重负，自然而然就分拆为不同的角色，形成了一个独特的架构体系。这一切的背后，仍然是为了提升人类自己的利益，解决人类自己的问题。
软件架构师，就是为了更好地完成这个过程